MySQL или PostgreSQL

MySQL
14
Нейтральная
сторона
1
PostgreSQL
3
Прежде чем писать комментарии или выбрать сторону вы должны авторизироваться!

23-09-2009 14:33 0

Будущее...

0 комментариев
23-03-2012 22:52 0

Ох уж эти старый вары на тысячи комментариев, да?

0 комментариев
24-03-2012 00:15 0

изначально MySQL была быстрее, а у PostgreSQL было больше возможностей. И те, и другие в последних версиях пытаются ликвидировать свои недостатки. mysql более распространен, поэтому я здесь.

0 комментариев
23-08-2013 01:03 +1

Оставлю для справки, вдруг кому-нибудь пригодится: www.wikivs.com/wiki/MySQL_vs_PostgreSQL

А сам присоединюсь к миллиону мух.

0 комментариев
23-08-2013 12:39 0



Раз пошла такая пьянка со сравнением типов данных, то как насчёт поддержки графов? Есть аналог хранилища OQGRAPH?

8 комментариев
Tro 23-08-2013 14:43 0

opera.rulez, У сайта холиворс-эффект - загрузился с третьего раза. Ура, товарищи!

Slimmer 23-08-2013 23:34 0

opera.rulez, я, вероятно, не слишком владею английским, но речь о рекурсивных (иерархических) запросах же? Тогда это скорее аргумент в пользу постреса - у них WITH RECURSIVE поизящней что ли... Я бы даже сказал это жирный минус мускулю.

opera.rulez 23-08-2013 23:47 0

Slimmer, Нет, не о рекурсивных запросах, а о хранении в базе специальных структур данных. В данном случае — о хранении в базе графов (деревьев и т. п., оттуда и слово «иерархических»).

Slimmer 23-08-2013 23:55 0

opera.rulez, не уловил разницы. В чем отличие?

Tro 24-08-2013 22:50 0

opera.rulez, Чем плох просто список рёбер (таблица из двух колонок)?

Slimmer 25-08-2013 09:01 0

Tro, проблема в способах обхода, насколько я понимаю. Вернее, в их ихначальном отсутствии

Tro 25-08-2013 14:00 +1

Slimmer, Загружаем таблицу в список смежности, а почти все способы прохода именно для него и делались.

Slimmer 25-08-2013 14:22 0

Tro, а sql- м как?

06-06-2012 11:05 +1

1)Дофига возможностей
Транзакции, полнотекст, индексы
2)Вменяемая лицензия
BSD - для бизнеса самое то
3)Очень быстрое развитие,намного быстрее, чем у MySQL.
4)И таки да, быстрее MySQL на серьёзной нагрузке.

1 комментарий
opera.rulez 22-08-2013 18:34 0

oktogen, 1) InnoDB
2) А тут поподробнее. Я плохо разбираюсь в лицензиях.
3) Список достижений в студию.
4) Результаты тестов в студию.

P.S. Полнотекст в СУБД не нужен, всё равно сторонний индексатор типа Sphinx его обойдёт.

22-08-2013 18:26 0

Странное соотношение сторон.

29 комментариев
opera.rulez 22-08-2013 18:30 0

Tro, ПОСТГРЕСА НЕТ НА ШАРЕДХОСТИНГАХ!!!11

Tro 22-08-2013 20:04 0

opera.rulez, А что действительно лучше для проекта с 10000+ пользователями? И что скажешь на отсутствие массивов в MySQL?

cherepets 22-08-2013 21:38 0

Tro, Массивы для геев. Курсоры (часто используются для тех же целей) и табличные переменные же есть.

opera.rulez 23-08-2013 00:48 0

Tro, Не в курсе. Но проекты с 100 000 000+ пользователями используют... А давайте посмотрим, что они используют.

Facebook: PHP с компилятором HipHop + memcached + MySQL + средства межсерверного взаимодействия.

Вконтакте: nginx + Apache + PHP + XCache + memcached + MySQL + cамописная нереляционная СУБД для ленты новостей + вспомогательные средства.

Многочисленные сайты знакомств: MySQL.

Твиттер: первоначально использовался собственный движок хранилища поверх MySQL. На новую СУБД перешли, когда количество пользователей стало исчисляться миллиардами.

Что они делают не так?

opera.rulez 23-08-2013 00:59 0

cherepets, Не знаю, про какие массивы говорит Tro, но Friendfeed, например, тупо засовывает все данные в одну ячейку типа BLOB: сериализация массива в строку + gzip. А для поиска и выборки создаёт отдельные таблички с индексами: backchannel.org/blog/friendfeed-schemale ...

И да, MySQL.

Tro 23-08-2013 01:13 +1

opera.rulez, Но это создаёт проблемы при одновременной работе.
Массивы.

opera.rulez 23-08-2013 10:28 0

Tro, Спасибо. Заманчиво, конечно, заполнять весь массив как одну строку. Да и возможностей больше, чем если засунуть массив в виде JSON в одну ячейку TEXT/BLOB.

Однако:
«Tip: Arrays are not sets; searching for specific array elements can be a sign of database misdesign. Consider using a separate table with a row for each item that would be an array element. This will be easier to search, and is likely to scale better for a large number of elements.»

Даже в руководстве Постгреса рекомендуют разворачивать массивы в случае необходимости поиска по элементам: одна строка — один элемент массива.

Хотелось бы посмотреть на живой проект, в котором понадобились массивы, т. е. где ни разворачивание, ни сериализация не годятся.

cherepets 23-08-2013 10:46 0

opera.rulez, Стоп, то есть массивы - это тип поля, а не переменной как я подумал?
//лень читать

opera.rulez 23-08-2013 11:35 0

cherepets, Догадайся:
CREATE TABLE tictactoe (
squares integer[3][3]
);

cherepets 23-08-2013 12:02 +2

opera.rulez, Бред. Если в поле хочется запихать массив, значит, база не нормализована.
Алсо, зачем используется здесь зубчатый массив, если размеры у всех записей одинаковый размер массива => память ты не экономишь? Неужели многомерные не поддерживаются?

opera.rulez 23-08-2013 12:28 0

cherepets, О том, что бред, говорит сама документация (цитату см. выше). Т. е. сами разработчики для больших массивов не рекомендуют использовать этот тип, а вместо этого рекомендуют нормализовывать базу.

Постгрес игнорирует в описании размер массива и количество размерностей, т. е. в каждой строке поле может иметь разный размер. Выходит, что храниться массивы должны аналогично текстовым полям или двоичным данным динамического размера.

P.S. Твой последний абзац я не понял.

cherepets 23-08-2013 12:38 0

opera.rulez, Последний абзац о том, что запись integer[3,3] понятнее и удобнее, чем integer[3][3] и в конкретно данном случае, вторая запись никаких преимуществ нам не несет.

cherepets 23-08-2013 12:41 0

cherepets, Кстати, а можно делать переменную массив то в итоге? У этого все же есть хоть какие то полезные применения :)

opera.rulez 23-08-2013 12:50 0

cherepets, • Массив может возвращаться селектом и даже быть значением выражения.
• Для массивов есть встроенные функции и операторы: www.postgresql.org/docs/9.1/static/funct ...

Правда, в примерах я не заметил переменного индекса, везде только константа.

Меня смущают транзакции. Ведь даже при построчной блокировке весь массив является лишь одним полем, следовательно, должен блокироваться целиком.

cherepets 23-08-2013 14:59 0

Tro, Кстати, совершенно ничего странного. MySQL тупо известнее.
И часто хостеры его ставят сразу => для сайтов он еще вечность будет самой популярной СУБД.

Конечно сайты - далеко не единственно применение баз, и на мой взгляд, даже не основное, но зато оно часто на слуху :)

Tro 23-08-2013 15:08 0

cherepets, Но не с таким же преимуществом. Когда я пришёл, соотношение не сильно отличалось от Google vs. Bing.

Slimmer 23-08-2013 23:39 0

opera.rulez, Меня смущают транзакции. Ведь даже при построчной блокировке весь массив является лишь одним полем, следовательно, должен блокироваться целиком.
И...? Ты хотел бы иметь возможность одновременно апдейтить одно и то же поле строки таблицы?

opera.rulez 23-08-2013 23:49 +1

Slimmer, Я бы хотел возможность одновременно апдейтить разные элементы одного массива. Если массив развёрнут (одна строка — один элемент), я это смогу. Если же массив свёрнут в одно поле, то придётся ждать. Стало быть, явных преимуществ перед сериализацией нет.

cherepets 23-08-2013 23:59 0

Tro, С таким.

Slimmer 24-08-2013 00:01 0

opera.rulez, Массивы как типы данных таблиц - это видимо реализация чьей-то хотелки. Другого объяснения я не нахожу. И этот кто-то быдлокодер, не имеющий представления об архитектурном подходе. У "амбициозных и динамично развивающихся проектов" такие залипухи встречаются иногда ;-) Партия сказала "надо" - программист стиснул зубы и реализовал.

Tro 24-08-2013 22:40 +1

opera.rulez, Сейчас читаю книжку по Постгресу. В пример использования массива приводится ежемесячная трата пользователем денег - элементов всегда двенадцать. Создавать для этого 12 колонок странно, базу из айдишников пользователя, месяцев и значения странно для задачи с фиксированным размером массива. Селект для отсеивания каких-нибудь тех, кто в месяц платит мало, написать можно (функция и FOREACH) - думаю, для таких целей вполне подходит. Не подходит для динамических массивов, что и написано в книге.

Slimmer 25-08-2013 09:00 0

Tro, Создавать для этого 12 колонок странно
зачем 12 колонок? если тебе важен вид расхода, то заведи такую колонку, а все суммы в одной записывай.
Мне кажется, единственный полезной момент в такой архитектуре может быть связан с тем, что ты сможешь быстрее получать доступ к блокам памяти этих записей в случае, когда ты выбираешь много элементов массива, чем когда ты по внешнему ключу обращаешься в другую таблицу. Но это нужно понимать архитектуру постгреса, чтобы такое однозноначно утверждать.

micron 25-08-2013 11:04 0

Tro, Костылябельно. Создаем ячейки фиксированного размера, а в заголовке (внутри блока с данными ячейки) каждой резервируем место с адресом продолжения, если оно есть.
Когда начинаем дописывать новую ячейку - информируем как-нибудь об этом другие процессы\сервера, которые могут туда что-то писать, чтобы они писали в offset+cellSize*n-1.

Создает проблему, идентичную той что наблюдаема в NTFS. Хотя можно смотреть вперед и использовать SSD, дополнительной фичей тогда будет точность предположений о сроках их отработки.

Slimmer 25-08-2013 11:27 0

micron, Создает проблему, идентичную той что наблюдаема в NTFS
можно поподробнее или пруф?

Tro 25-08-2013 14:30 0

micron, offset+cellSize*n-1
Вот такая привязка уже более костылябельна.

Tro 25-08-2013 14:31 0

Slimmer, Тут не вид, а то, сколько юзер за каждый месяц заплатил. Таких значений 12.

Slimmer 25-08-2013 14:54 0

Tro, ну ты ж понимаешь, что это не меняет смысла того, что я предложил...

micron 25-08-2013 15:45 0

Slimmer, Фрагментация же. Это исходит из самого механизма - если нам нужно увеличить старую ячейку, то экономнее допилить новый блок снизу, чем физически увеличивать старую ячейку, еще и переделывая индексы для данных выше по оффсету.

Что еще интересно прикостылять - это дефрагментатор, который будет способен работать без необходимости приостанавливать работу сайта.

как попиливать собственную СУБД и не догадыватся об этом

Tro 25-08-2013 16:27 0

Slimmer, Тогда я тебя не понял.

13-09-2013 17:49 0

Пока я всё ещё набираю мощь в синей теме и не сильно способен полностью облить MySQL (для чего и зелень придётся изучить), предлагаю поговорить об отсутствии в MySQL наследования.

12 комментариев
cherepets 13-09-2013 17:53 +1

Tro, Изучать СУБД ради холивара на сайте, где с обеими СУБД детально знакомо ~0 человек?
Неужели у тебя так много свободного времени?

Про наследование: а зачем оно в SQL? Приведи полезный кейс.

Tro 13-09-2013 18:00 0

cherepets, Про наследование: а зачем оно в SQL? Приведи полезный кейс.
Наследование таблиц.
Например, есть у меня несколько типов пользователей (физические, юридические лица, роботы и т. д.), которых объединяет лишь айди, логин и пароль. Создаю таблицу users, где есть айди, логин и пароль. Потом создаю для физлиц, где создаю какие-нибудь ФИО, паспортные данные, и наследую её от users. При добавлении элемента в таблицу физлиц, будет автоматически пополнена users. Юрлица и роботы тоже будут добавляться в общую для всех таблицу users. Можно это использовать для единого входа.

cherepets 13-09-2013 22:58 0

Tro, Чем не устраивает тупо в таблице сделать поле с id из users и задать связь?

Tro 13-09-2013 23:09 0

cherepets, Дольше реализовывать, делать два инсерта при добавлении нового пользователя.

cherepets 13-09-2013 23:12 0

Tro, Сделать хранимку и забыть о способе реализации на вечно.

Slimmer 13-09-2013 23:31 0

Tro, а так ты инсертом в дочернюю таблицу вставишь поля в родительскую?

Tro 13-09-2013 23:42 0

Slimmer, Не понял отношения к этому комменту. Если оно к комменту про наследование, то там всё автоматом делается.

Slimmer 14-09-2013 08:14 +1

Tro, судя по первой ссылке из поиска, про инсерт ты не прав. Т.о. единственная фишка данной технологии только в том, что бд сама за тебя сделает join при селекте? ИМХО, сомнительное преимущество и вообще порочная практика, наверняка замедляющая вставку и апдейт таких таблиц.

cherepets 14-09-2013 11:42 0

Tro, Можно кстати, повесить триггер на вставку в физлиц, который будет осуществлять вставку и в users. В итоге тоже нужен будет 1 INSERT для вставки в обе таблицы.

Slimmer 14-09-2013 11:58 0

cherepets, как триггер узнает значения полей родительской таблицы?

cherepets 14-09-2013 17:31 0

Slimmer, А, ну да, в дочерней же лишних полей не будет.. Или пусть будут, причем зануляемые и триггер их как раз будет обнулять.
Но это уже слишком костыльно.

Tro 14-09-2013 19:28 0

Slimmer, Я говорил в катах, что там не инсерт. Да, замедляет - поэтому я использование ограничу авторизацией.