Поприветствуйте вашего старого нового друга

Автор оригинала: Rob Conery
  • Перевод
Сегодня разнообразные открытые СУБД встают лицом к лицу против массивных, неуклюжих и дорогостоящих «корпоративных» систем, таких как SQL Server и Oracle. Часто открытые СУБД прекрасно работают лучше закрытых систем, не уступая даже в функциональных возможностях.

Из всех открытых систем управления базами данных самой умной, производительной и функциональной системой является Postgres, которая заслуженно привлекает всё больше и больше внимания.

Уже одно только название продукта вызывает неподдельный интерес у читателя: «эй, какого чёрта оно так называется?!» На этот вопрос хорошо ответил один из разработчиков — Том Лэйн, в списке рассылки pgsql-novice:

Правильное название — PostgreSQL или Postgres, но не “postgre”. Вероятно, принятое в 1996 году решение назвать систему PostgreSQL вместо простого Postgres является единственной чудовищной ошибкой за всю историю проекта. И я думаю что сейчас уже поздно что-то менять.

Проект Postgres являлся попыткой переработки очень старой СУБД Ingres с целью создания модульной, масштабирумой, производительной системы управления базами данных, удобной для конечного пользователя тех времён. Таким образом предполагалось, что название “POSTgres” будет являться отсылкой к родительскому проекту — “After Ingres”. Так получилось.

Кого это волнует?


В действительности, это волнует не так уж много людей. Бурный рост популярности языка PHP сопровождался достаточно интенсивным развитием более «дружественной» платформы MySQL. Да, проект MySQL развивался значительно быстрее, чем более строгая платформа Postgres. К сожалению, вместо дружественности приходится говорить о глупости.

Это сильное утверждение, но давайте попробуем его обосновать. Например, вот этим видео, что я недавно залил на Tekpub под названием «Опасности MySQL». Приведу краткое содержание видеоролика, если у вас нет возможности или желания его смотреть:

  • MySQL, будучи недостаточно строгой СУБД, задорно игнорирует ваши настройки и ограничения целостности (она просто хочет помочь);
  • она легко вставит пустую строку "" в колонку с запретом на добавление пустых значений;
  • она с радостью вставит бесполезные даты (вроде 0000-00-00) в колонки с датами при запрете добавления пустых значений;
  • она умеет делить на ноль и вернёт NULL при вычислении 1/0;
  • она вернёт NULL при делении строки на ноль;
  • если вы попробуете вставить значение 1000 в колонку с длиной равной двум, то она просто немного округлит это значение до 99.

Всё это должно дать вам повод задуматься об использовании MySQL: эта система не проверяет ваши данные, зато она пытается показаться «удобной» ценой целостности данных. Мне кажется, это довольно плохо.

Если ничего из вышеизложенного не повергло вас в ужас, то у меня есть единственное слово про вас: Oracle.

Быстро, масштабируемо, весело


Функциональность Postgres достаточно обширна, и многие люди даже не подозревают о возможностях этой СУБД. Стоит отметить, что система обладает таким синтаксическим сахаром, как:

  • ключевое слово “infinity”, означающее «больше, чем любое введённое значение» — работает для чисел и дат;
  • нежные выражения для работы с датами: “today”, “tomorrow”, “yesterday” (и в Postgres 9.2 всё будет ещё лучше);
  • замечательные типы данных: массивы, IP-адреса (с поддержкой IPv6), а также пространственные типы данных (линии, квадраты, круги);
  • наследование таблиц — хитрая возможность унаследовать одну таблицу от другой;
  • полнотекстовый поиск по неструктурированному тексту на естественном языке — из коробки.

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

У меня есть друг. Его зовут Роб Салливан и он DBA. Вместе с ним мы провели небольшой эксперимент: загрузили в Postgres архив данных StackOverflow, содержащий шесть миллионов текстовых записей. После этого мы расчехлили свои инструменты (для запросов к базе данных) и начали оптимизировать нашу систему, сравнивая её поведение с поведением SQL Server. Postgres не просто показал сравнимую производительность, он во многих случаях значительно превзошёл решение от Microsoft!

Отдельные слова стоит посвятить индексированию. Благодаря наследованию таблиц мы легко можем партиционировать таблицы и выжать из СУБД лучшую производительность благодаря сокращённому объёму индекса. Конечно, это можно реализовать и средствами SQL Server, но эта задача решается не столь очевидно, а также требует приобретения дорогостоящей лицензии.

И это ещё не всё! Прямо из коробки Postgres умеет сжимать таблицы на лету: этот подход получил название “TOAST”, образованное от фразы “Automatic Table Compression”. Благодаря сжатию данных сокращается потребление как ОЗУ, так и дискового пространства.

Благодаря TOAST нам удалось снизить место, занимаемое данными из StackOverflow с двадцати четырёх гигабайт до шести гигабайт, и это довольно серьёзная экономия. Эта возможность бесплатна и включена в стандартную поставку Postgres. Для использования этой возможности в SQL Server необходимо приобрести Enterprise-лицензию.

Пять вещей, которые вы не знаете


О возможностях Postgres можно писать много, очень много. Вместо этого я просто дам вам ссылку на мой доклад с конференции NDC 2012: «Пять вещей, которые вы не знаете о PostgreSQL». В докладе я рассмотрел такие нюансы, как:

  • выполнение запросов к Twitter при помощи механизма foreign data wrappers;
  • написание функций на JavaScript при помощи движка V8 от Google;
  • убойные трюки с MySQL;
  • предотвращение блокировок при помощи встроенного в Postgres механизма снимков;
  • наследование таблиц;
  • чумовые типы данных.

Надеюсь, вам понравится.
Поделиться публикацией

Похожие публикации

Комментарии 111

    +1
    Работаю с MySQL, но давно уже присматриваюсь к PostgreSQL. Заинтересовало использование CTE для организации рекурсивных запросов и пользовательские типы данных, которые не поддерживаются в MySQL.
      +5
      Раньше использовал MySQL. Два года назад перешел на PostgreSQL. Не пожалел. Оно того стоит. Личное впечатление: «отличаются как небо и земля»
        +1
        А конкретнее. Какие профиты вы получили?
          +1
          По моему опыту — несопоставимо качество работы оптимайзера запросов. На чуть сложных запросах MySQL норовит свалиться в full table scan с соответствующим влиянием на производительность, PostgreSQL же честно разруливает сложные запросы и выполняет их гораздо быстрее.
            0
            Постгрес тоже часто на сложных запросах в full table scan сваливается — я несколько раз за последние пару лет наткнулся. 9.1 значительно лучше 8.х в этом отношении, конечно.
              +1
              Странно, у меня (при условии нормально проставленных индексов) такого не встречалось — а запросы были очень сложными. Но даже если такое действительно встречается (может, мне просто везло) — всё равно, с mysql никак не сравнить.
                0
                один случай был — при большом количестве JOIN-ов, оптимизатор учитывал только первые 6-8 JOIN-ов (у постгресса в настройках есть параметр), а остальные не оптимизировал. Получалось, что смена порядка JOIN-ов изменяла скорость выполнения запроса в раз в 20. Это дело было починено в 9.1. Другой случай — в сложном запросе был sub-query, который по логике должен был запущен 1 раз, а запрос с ним выполнялся в 100 раз медленнее, чем должен был. Тоже было починено в 9.1, а в 8.4 помогла замена на JOIN. Ну и прилично было таких случаев. Был даже случай, когда 9.1 начал тормозить на запросе, нормально выполнявшемся в 8.4, но не помню уже, в чем там дело было.
      +7
      Сегодня разнообразные открытые СУБД встают лицом к лицу против массивных, неуклюжих и дорогостоящих «корпоративных» систем, таких как SQL Server и Oracle. Часто открытые СУБД прекрасно работают лучше закрытых систем, не уступая даже в функциональных возможностях.

      Всегда любил такие высказывания. Особенно ничем не подкрепленные.

      У меня есть друг. Его зовут Роб Салливан и он DBA. Вместе с ним мы провели небольшой эксперимент: загрузили в Postgres архив данных StackOverflow, содержащий шесть миллионов текстовых записей. После этого мы расчехлили свои инструменты (для запросов к базе данных) и начали оптимизировать нашу систему, сравнивая её поведение с поведением SQL Server. Postgres не просто показал сравнимую производительность, он во многих случаях значительно превзошёл решение от Microsoft!

      А MSSQL при этом оптимизировали, или нет? И где результаты тестов в цифрах?
        +1
        Это перевод, и автор оригинальной статьи наверняка ответит на все вопросы. Странно, но хабр не подсвечивает тег <abbr>, которым размечено второе предложение.
          +8
          Я знаю, что это перевод. Но если уж кто-то его здесь разместил, то его и пообсуждать здесь можно, не так ли?

          (а иначе в чем смысл)
            +5
            Так а в чём проблема? Гуглим по Postre vs SQL server и находим кучу сравнений. Почти всегда — закономерно не в пользу последней кроме странных синтетических случаев. Уже давно Postrgre считается самой адекватной свободной СУБД, практически не уступающей и во многом превосходящей оракл и тем паче MSSQL. Эта характеристика за постгрёй закрепилась не просто так, так что изначальный автор по сути просто ещё раз про неё напомнил.
              –3
              Гуглим по Postre vs SQL server и находим кучу сравнений

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

              Вообще-то бремя доказательства лежит на утверждающем.

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

              А что в этом закономерного?
                +1
                А что в этом закономерного?


                Вы не опенсорс-фанатик, должно быть. Тогда что вы тут делаете? ;)
                  +2
                  Любопытствую альтернативами MS SQL.
                    +2
                    Сережа, все правда так про постре. Оно как минимум не хуже)
                      +3
                      Все зависит от задачи. Ваш К.О.
                        +3
                        Но задачи у PostgreSQL и MS SQL/Oracle те же. Это реляционная БД, масштабируемая, очень стабильная и современная.

                        С MS SQL работать не довелось; но существенных проблем с PostgreSQL по сравнению с Ораклом совершенно точно в наших внедрениях не было. Более того, Постгрес значительно проще в администрировании.
                          0
                          Но задачи у PostgreSQL и MS SQL/Oracle те же.

                          Вы не учитываете такую маленькую и незаметную «задачу» как необходимость быть совместимыми со всем остальным стеком используемого ПО.
                            +2
                            :)

                            Да уж, вот тут у продуктов MS под виндой конкурентов быть по определению не может. Они ж столько лет на это работали…

                            … и всем по-прежнему все равно. Я к тому, что на корпоративном рынке мало кто руководствуется благом техническим.

                            Тот же Оракл на Server Edition довольно жутко вкатывается. Молчу уж про то, что он достаточно нетривиально удаляется, оставляя за собой либы и непонятный мусор в реестре.
                              0
                              … и всем по-прежнему все равно. Я к тому, что на корпоративном рынке мало кто руководствуется благом техническим.

                              Ну, вы за всех-то не говорите. Вполне себе есть проекты, где делают оценку совместимости.
                                +1
                                За всех говорить не буду. Локально встречаются начальники отделов и ведущие разработчики, старающиеся держать хотя бы свои участки в чистоте и порядке.

                                Но возьмем среднюю такую корпорацию тысячи эдак на четыре человек. Там будет SAP, будет заказной софт на Джаве и будет заказной софт для .NET. И Оракл тоже будет — для Джавы той же. И MS SQL — для .NET, который тоже где-нибудь рядышком найдется.

                                И все эти сотни тысяч — если не миллионы — строк еще через какую-нибудь шину должны будут переплевываться сообщениями…

                                А как так вышло? Вышло так, потому что в 2007 был один зам, который протолкнул свое решение. Через четыре года — другой. Еще одно решение. А когда-то кто-то еще что-то…

                                Я, кстати, про реальную корпорацию говорю. И ведь не потому так вышло, что какой-то из отделов плохо свою работу делал…
                                  0
                                  Я, кстати, не вижу в описанной ситуации ничего плохого.

                                  Я как раз хочу сказать, что находясь в подобной ситуации .net-разработчик скорее уж выберет mssql, чем postresql. Поэтому «не хуже» окажется весьма субъективным.
                                    +3
                                    не вижу ничего хорошего в разнобое, это просто такие рабочие реалии.

                                    Акцент был на другом. Внедрение стека .NET или Java — вопрос, который часто определяется не архитектурными соображениями, а связями тех или иных людей, ответственных за решения.

                                    И пофиг, кто и что лучше знает…
                                      +1
                                      А разница между «связями» и «кто, что лучше знает»? В обоих случаях это не объективное ТЭО, а субъективный выбор.
                                        +1
                                        Эт точно, субъективный.

                                        Но хрен ведь сравнишь такого калибра системы, тем более — со стороны. Бывают, конечно, принципиальные киллер-фичи или принципиальные технические ситуации, но уж точно не в случае выбора между PostgreSQL и Oracle.
                                          0
                                          Иногда — нужно взять любой ценой — тогда побеждают монстры вроде Oracle, здесь не поспоришь. Иногда — приходится считать сколько «копеек» заплатить за фичу, тогда всё совсем не однозначно.

                                          Например, горизонтально смасштабировать приложение на low-cost оборудовании — это однозначно не про Оракл или MS. При этом возможности Postgres — это не такая уж и наколенная поделка, если разобраться. Ряд интегрируемых в базу языков, таких как Python или R, развитая система типов, делающих Postgres гибридом реляционных и модных нынче NoSQL решений, позволяющая соединить плюсы обоих подходов.
                                          Скажем, по моему субъективному мнению, Postgres на голову выше Firebird и иже с ним коммерческого Interbase по ряду возможностей (по крайней мере так было лет пять назад, когда я интересовался вопросом, и именно нужных мне возможностей).
                                0
                                >Да уж, вот тут у продуктов MS под виндой конкурентов быть по определению не может.

                                Почему? Постгрес прекрасно крутится на винде.
                                +1
                                От «стэка» зависит. Если продукт напрямую не завязан на MS SQL Server, то скорее он использует что-то вроде ODBC или другой DBAL.
                                  0
                                  И вот как вы определяете «напрямую завязан на»?
                                    0
                                    В системных требованиях смотрю :)
                                      0
                                      Вот дело в том, что есть куча софта, у которого в требованиях не написано, но де-факто с MS SQL работает из коробки, а с другим софтом требует бубна.
                            –2
                            Если бы вы работали с пространственными данными в postgres и mssql — то знали бы что postgres очень сильно уступает в производительности с пространственными данными
                        +5
                        А для чего утверждающему Вам что-то доказывать? Не хотите гуглить — значит тема не особо и интересна, просто забудьте.
                        +1
                        Правильное название — PostgreSQL или Postgres, но не “postgre”.
                        :)
                    +7
                    А MSSQL при этом оптимизировали, или нет? И где результаты тестов в цифрах?

                    Подозреваю, что сравнивали с боевой конфигурацией stackoverflow, и что-то мне подсказывает, что там она тоже оптимизированная. Но все равно тут могут оказаться нюансы, например Postgres могли взять и оптимизировать исключительно на чтение, в то время, как sql server на stackoverflow еще и активное наполнение/изменение данных.
                    +10
                    Спасибо автору за перевод, но статья больше походит на «холивар-мину».

                    <sarcasm>
                    > К счастью, с этими вещами у Postgres полный порядок.
                    Звучит убедительно.

                    > чумовые типы данных.
                    Killer-feature.
                    </sarcasm>
                      +8
                      > Killer-feature.

                      Вот Вы конечно можете сомневаться, но всё-таки это — действительно killer-feature.

                      Один только тип hstore стоит хорошей статьи на хабре — тип, превращающий поле в key-value хранилище, с операциями манипуляции над ключами как множествами и полноценной индексацией всего этого добра — из коробки.

                        +4
                        Никаких сомнений, просто тема ну ни капельки не раскрыта!
                        Вот если бы ка вы в двух словах написали было бы намного информативнее или хотя бы в скобочках перечислили имена этих «чумовых» типов.
                          +1
                          если честно, у меня не получается придумать применения этой фиче в работе.
                          если у вас есть опыт использования этой штуки, поделитесь пожалуйста, было бы очень интересно почитать про реальное использование, а не синтетические примеры.
                            +1
                            Список свойств товаров.
                              0
                              в чём преимущество хранения списка свойств товара в одном поле перед хранением списка свойств в виде отдельных записей в таблице?
                                +4
                                hstore удобно использовать, когда список свойств часто меняется, или отличается от объекта к объекту. Когда можно было бы использовать отдельную таблицу для хранения key-value пар, hstore часто оказывается удобнее и быстрее, и бесплатно дает возможность делать запросы, которые при отдельной таблице были бы сложнее.

                                Зачастую, если нужно указать какое-то дополнительное свойство или пару для какого-то объекта, делать для этого отдельную колонку в таблице неудобно. А создавать таблицу key-value еще более неудобно.

                                Для меня важный плюс — это делает проще код. Например, ипользуя django-hstore, им пользуешься как обычным словарем. В противном случае было бы намного больше строк, даже учитывая ORM.
                                  0
                                  Значительно проще, как с точки зрения программиста, так и с точки зрения планировщика, построение запросов, более компактное расположение данных — в отдельной таблице связанные записи могут быть очень разбросаны по дисковым страницам, в одном поле же, они хранятся на минимально необходимом количестве страниц, ещё и хранятся со сжатием, не нужен дополнительный индекс для выборки по ключевому полю и само ключевое поле для связки, меньше памяти нужно для построения плана запроса, меньше размывается кеш за счёт чтения не нужных в данный момент страниц при больших таблицах. Это так, навскидку — возможно ещё что-то не учёл или не знал
                                    0
                                    ну а если, положим, я хочу сделать поиск по товарам, обладающим каким-либо свойством? если они лежат списками в специализированных полях, то субд при поиске вынуждена залезать в каждое такое поле, парсить его, искать в нём нужное значение и только потом сравнивать с запросом. сжатие дело хорошее, но когда нужно найти среди пары миллионов записей те, которые обладают тем или иным свойством, оно по-моему скорее затормозит работу, чем ускорит.

                                    но самое главное, что я хотел бы уточнить — как с такими списками контролировать целостность данных? можно ли на уровне субд накладывать на них ограничения? если я храню свойства товаров в отдельной таблице, то я могу заранее определить список свойств и субд будет контролировать сама, что никаких других свойств у товаров появиться не может, т.е. никто не сможет завести у одного товара свойство «цвет», у другого «цвет корпуса», а у третьего «расцветка» — у всех свойство будет называться одинаково и соответственно поиск будет более релевантным. а можно ли аналогично ограничивать множество значений в hstore?
                                      +2
                                      В постгрес есть два типа индексов: GIST и GIN, которые хорошо подходят для индексации множеств, каждое со своими особенностями — на этом построен и полнотекстовый поиск. GIST быстрее на создание и модификацию, GIN — эффективней на поиске при больших множествах значений, таких как множество слов в языке.

                                      Просто логические ограничения накладывать можно — можно создавать произвольные constraint'ы. Более сложные ограничения, зависящие от данных в других таблицах — только строить через триггеры (и эта задача может оказаться нетривиальной, но это уже отдельная тема).

                                      Ссылочная целостность данных — на уровне базы не контролируется и это в какой-то степени минус данного решения. Но поле hstore можно использовать как кеш для таблицы связей, а триггеры на изменения в таблице связей просто будут обновлять соответствующее поле в основной таблице. Полагаю всё зависит от особенностей задачи и эксплуатации базы.
                          +1
                          Кстати, касательно возможностей PostgreSQL, кому приходилось использовать на практике:
                          — наследование таблиц;
                          — тип данных массив.
                          Поделитесь пожалуйста опытом: для решения каких задач использовалась данная возможность?
                            +3
                            Если мне не изменяет память, то на предыдущей работе массивы использовались для хранения списка категорий продукта в товарном каталоге при денормализации данных. Postgres имеет возможность выполнять запросы над массивами как над обычными таблицами. Благодаря этому можно было фильтровать, агрегировать и выдавать данные без лишних преобразований.
                              +1
                              1. Использовалось для натягивания на БД объектной структуры бизнес-модели. Не спрашивайте, зачем :-)
                              В 2008 году ни один известный на тот момент ORM это не переваривал, и мы использовали iBatis.
                                +1
                                Я не использовал ни то, ни другое (просто я постгресом почти не пользовался), но, это довольно очевидно:

                                наследование может пригодиться в таком кейсе например: вы строите простейшую crm-систему, у вас есть сущности сделок, контактов, тасков. мало того, что это довольно логично, создать базовую сущность (ну как минимум для контактов и сделок), так к тому же это поможет решить проблему дэшборда, где надо вывести и сделки и контакты, etc

                                а типы данных в виде массива пригодятся тогда, когда данные просто нет смысла нормализовывать. опять же юз-кейс на примере црм — у контакта может быть много телефонов, и вам совершенно не зачем выносить их в отдельную таблицу и связывать как many-to-many, т.к., ну, это не нужно, в этом нет потребности
                                  +3
                                  К сожалению, не наследуются констрейнты.
                                  +2
                                  Это из задачи составления расписания и части документооборота в ВУЗе
                                  Таблицы
                                  CREATE TABLE tblПотоки (
                                    pk_поток                SERIAL PRIMARY KEY,
                                    fk_надПоток             INTEGER REFERENCES tblПотоки(pk_поток),
                                    fk_учебныйГод           INTEGER REFERENCES tblУчебныеГода(pk_учебныйГод) NOT NULL,
                                    fk_факультет            INTEGER REFERENCES tblФакультеты(pk_факультет) NOT NULL,
                                    название                TEXT NOT NULL,
                                    дополнение              HSTORE,
                                    UNIQUE(fk_учебныйГод, fk_факультет, название)
                                  );
                                  
                                  CREATE TABLE tblГруппы (
                                    pk_группа               SERIAL PRIMARY KEY,
                                    fk_формаОбучения        INTEGER REFERENCES tblФормыОбучения(pk_формаОбучения) NOT NULL,
                                    fk_специальность        INTEGER REFERENCES tblСпециальности(pk_специальность) NOT NULL,
                                    курс                    INTEGER NOT NULL,
                                    комм                    BOOLEAN NOT NULL,
                                    колБюджет               INTEGER NOT NULL,
                                    колКомм                 INTEGER NOT NULL,
                                    дополнение              HSTORE
                                  ) INHERITS (tblПотоки);
                                  
                                  CREATE TABLE tblПодгруппы (
                                    pk_подгруппа            SERIAL PRIMARY KEY,
                                    fk_группа               INTEGER REFERENCES tblГруппы(pk_группа) NOT NULL,
                                    fk_разбиение            INTEGER REFERENCES tblРазбиения(pk_разбиение) NOT NULL,
                                    колБюджет               INTEGER NOT NULL,
                                    колКомм                 INTEGER NOT NULL,
                                    дополнение              HSTORE
                                  ) INHERITS (tblПотоки);
                                  

                                  Представление
                                  CREATE VIEW vwПотоки AS
                                  WITH RECURSIVE Потоки(fk_поток,  fk_группа, fk_подгруппа) AS (
                                      (SELECT
                                        tblГруппы.pk_поток, tblГруппы.pk_группа, NULL
                                      FROM
                                        tblПотоки tbl1 INNER JOIN tblГруппы ON tbl1.pk_поток = tblГруппы.pk_поток)
                                    UNION
                                      (SELECT
                                        tblПодгруппы.pk_поток, NULL, tblПодгруппы.pk_подгруппа
                                      FROM
                                        tblПотоки tbl2 INNER JOIN tblПодгруппы ON tbl2.pk_поток = tblПодгруппы.pk_поток)
                                  UNION ALL
                                    SELECT
                                      tbl3.fk_надПоток, Потоки.fk_группа, Потоки.fk_подгруппа
                                    FROM
                                      tblПотоки tbl3 INNER JOIN Потоки ON tbl3.pk_поток = Потоки.fk_поток
                                    WHERE
                                      tbl3.fk_надПоток IS NOT NULL
                                  )
                                  SELECT
                                    *
                                  FROM
                                    Потоки;
                                  

                                  Много пробовал, но по другому получается плохо. Создание view можно будет упростить, когда в PostgreSQL встроят Grouping Sets
                                    0
                                    Я это использовал для шардинга (как и автор)
                                      0
                                      s/это/наследование/
                                      +2
                                      Я наследование использовал для базы данных сайта недвижимости. Данная предметная область содержит в себе объекты недвижимости, которые имеют ряд общих свойств (id, адрес, стоимость, владелец, и т.д.) и различаются по типу недвижимости (квартира, офис, склад, и т.д.) и некоторым частным свойствам присущих специфическим типами недвижимости.

                                      Так вот, у меня была одна общая таблица, содержащая все общие данные об объектах недвижимости, и несколько наследуемых таблиц, по одной для каждого типа недвижимости, содержащии специфическую информацию.

                                      С такой структурой было очень удобно работать, потому что у меня была таблица со всеми общими данными по всем объектам недвижимости вне зависимости от типа, и у меня был набор таблиц содержащих полную информацию о конкретном типе недвижимости. При этом данные не дублировались в базе данных, что очень удобно.
                                        0
                                        На самом деле, насколько я вижу, люди только для избегания юниона и используют наследование )
                                        Не хочу сказать что это плохо, просто заметил
                                          0
                                          Да согласен что данную возможность можно реализовать c использованием view (в котором union-ятся таблицы), но все таки этот вариант больше подходит для задач на чтение данных. С другой стороны, имея родительскую таблицу, мы можем вносить изменения в структуру таблицы, и эти изменения будут автоматически применены в наследуемых таблицах. Плюс я все таки подозреваю что на уровне реализации, данная возможность (наследование) реализованна умно, что в свою очередь позволяет сэкономить ресурсы.
                                        +1
                                        >>Кстати, касательно возможностей PostgreSQL, кому приходилось использовать на практике:
                                        >>— наследование таблиц

                                        Открыл для себя наследование в постгре благодаря вопросу в QA.

                                        Использование наслдеования, имеет вполне документированные подводные камни, и, фактически, заставляет отказаться от таких чтук, как PK/FK, что очень сужает область применимости до ничтожной.
                                        0
                                        Так StackOverflow таки работает на Postgres?
                                        –2
                                        «Из всех открытых систем управления базами данных самой умной, производительной и функциональной системой является Postgres, которая заслуженно привлекает всё больше и больше внимания.»

                                        Ушел сносить с боевых серверов оракл и ставить Postgres.

                                        Надо, чтобы надпись «Перевод» была гораздо крупнее и жирнее, а то хочется ушат сразу вылить на того, кто запостил, а не автора оригинального поста ;)
                                          +2
                                          Еще один огромный бонус постгреса для меня, это JSON как тип: www.postgresql.org/docs/devel/static/datatype-json.html
                                            +1
                                            Я всем рекомендую расширение hstore. За счет его введения устраняется один из основных недостатков реляционных баз данных.
                                            0
                                            Коллеги, а можете порекомендовать проверенное и 100% рабочее без костылей решение для master-master репликации?
                                              0
                                              Родного нет пока. Даже синхронная мастер-слейв репликация появилась только что. Недавно читал, что в MySql мастер-мастер асинхронный, со всеми вытекающими… Пруф не нашёл, может знающие опровергнут. Сам я мускуль стараюсь не юзать.
                                              +15
                                              Вместо Oracle и MS SQL использовать Postgres и MySQL?

                                              А теперь дружно подумаем, почему если есть такие замечательные бесплатные средства как MySQL & Postgres, большие серьезные компании настойчиво продолжают использовать Oracle или MS SQL? Или еще большую экзотику Informix, Progress, etc ???

                                              Такие сравнения все от лукавого по сути. Понятно что для веб-разработки можно использовать бесплатные решения и радоваться жизни, однако, как только в ваш лексикон добавляется хотя бы слово OLAP, на бесплатных СУБД становится грустно. Назовите мне хоть одно решение для бизнес-аналитики на данных бесплатных СУБД? Тот и оно! Я конечно знаю про аналитические запросы в Postgres, но давайте быть честными это же совсем не тоже самое что MDX.

                                              Их можно прекрасно использовать для OLTP, но не более. А зачастую потребности бизнеса это не «штоб все круто и быстро было», а «штоб быстро и круто можно было строить аналитические отчеты».

                                              Многие конечно никогда с этим не столкнутся. Многие не используют и на 20% возможности MySQL и Postgres используя ORM считая это за истинное благо. Мало кто использует всю мощь данных СУБД. И в данном контексте даже ActiveRecord не всегда будет удобен, хотя по сути является этакой «лайт» версией ORM.

                                              Слишком уж «синтетические тесты» приведены в статье, по сути не всегда можно взять Postgres и радоваться жизни, я бы конечно очень хотел чтобы на Postgres можно было делать бизнес-аналитику, но реалии другие. Даже если строить серьезный(подчеркиваю серьезный) интернет магазин, то OLAP уже маст-хев сразу же. Потому что аналитика, потому что прогнозирование.

                                              Можно конечно сделать проще — для OLTP использовать свободные СУБД, а для Bussiness Intellegence покупать коммерческие, однако многим организациям проще держать одну СУБД, да и зачастую когда покупается СУБД, она либо покупается вместе с продуктом где используется аналитика, либо в архитектуру изначально заложена составляющая аналитики, и когда покупаются коммерческие СУБД, они не выбираются по принципу «Это круто», а в следствии полноценного анализа будущей архитектуры приложения.

                                              Если уж и сравнивать СУБД, то вероятно их надо сравнивать не только по принципу скорости SELECT & INSERT. В том же MySQL есть свои плюсы для высоконагруженных систем, которые уделают PostgreSQL. C другой стороны и в Postgres полно магии подобно oid, tid, etc аналогов которых в MySQL я не знаю (возможно в силу того что давно не использовал MySQL).

                                              Как-то так. Было бы интересно если бы кто либо написал бооольшой такой огроменный пост о реальном сравнении о функциональных возможностях и особенностях хотя бы самых известных СУБД. А не анализ по синтетическим тестам которые всем уже надоели да и не отражают действительности в плане функционалаи его необходимости для конкретных задач. А то так можно и договорится до того что SQLite самый крутой так как у него INSERT шустрее чем у других.

                                              PS:
                                              Я не говорю что одна СУБД хуже другой. Все СУБД разные и то что годится для одной задачи, может не подходить под другую, кому-то будет удобнымиспользование «микса» из разных СУБД, кому-то проще будет вложится в коробочное решение.

                                                0
                                                В принципе, со всем согласен (особенно с последним абзацем), но хотел бы уточнить, что OLAP для PostgreSQL всё-таки есть.
                                                  0
                                                  Ну я бы все таки сказал что это «коробочное решение», хотя я может не прав. Не попадался мне GreenPlum на моему Пути )
                                                    0
                                                    Блин конечно же НЕ «коробочное решение». Извиняюсь за опечятки, не освоился еще с набором текста на планшете.
                                                  0
                                                  Не холивара ради, но почему Вы считаете, что Postgres подойдет для OLTP, но для BI нет?
                                                  Мне казалось, что для того чтобы сделать BI СУБД должна уметь партиционирование, индексы, процедуры и ETL.
                                                    0
                                                    Ну сделайте =) можно конечно сделать ROLAP с SQL запросами, но дать это аналитикам… ) как то жестоко
                                                      +4
                                                      Автор замечательной книги PostgreSQL 9.0 High Performance, который довольно активен в сообществе PostgreSQL, хоть и является приверженцом этой СУБД, честно пишет в этой книге, что на данный момент времени коммерческие базы больше подходят для data analytics, потому что в постгресе некоторых вещей, нужных для этого, просто нет. И известный бенчмарк TPC-H в postgres выполняется несоизмеримо медленнее чем в коммерческих субд.

                                                      Тем не менее, postgres прекрасно подходит для нужд большинства проектов.

                                                        0
                                                        Теперь все меняется. На основе Postgresql есть AWS Redshift, CitusDB, Greenplum, Apache Hawk
                                                      +3
                                                      А теперь дружно подумаем, почему если есть такие замечательные бесплатные средства как MySQL & Postgres, большие серьезные компании настойчиво продолжают использовать Oracle или MS SQL?

                                                      Аналогичный вопрос: почему в крупных компаниях корпоративным стандартом до сих пор является IE-8? Ведь есть же отличные бесплатные хром и фаерфокс. Проводить тесты, обсуждать Killer-feature и доказывать что Chrome/FF лучше IE-8 — бесполезно. Есть какое то другое объяснение.
                                                        0
                                                        Есть какое то другое объяснение.

                                                        Управляемость доменными политиками, например?
                                                          +2
                                                          Фаерфокс это умеет
                                                            0
                                                            А админы и какой-нибудь WSUS/MSSC это умеют? Первый пункт важнее.
                                                            +1
                                                            Умеют. Вы еще начните доказывать, что аналогов AD/AD LDS для RHEL не найти!
                                                              0
                                                              Комментом выше я уже написал: кроме того, что это должен уметь софт, это еще должны уметь админы и управляющий софт в компании.
                                                                +1
                                                                Админы умеют то, что надо уметь. Уж разобраться с Лисом можно и без трехмесячного тренинга в Штатах! Это ж не SAP!

                                                                Впрочем вам, вероятно, виднее. Я, к счастью, давно уже не занимаюсь корпоративным софтом. По старой памяти зацепился. :)
                                                                  0
                                                                  Админы умеют то, что надо уметь.

                                                                  Это стоит денег. Как следствие, это должно быть чем-то оправдано. А IE встраивается в экосистему «из коробки» и (практически) не требует дополнительных затрат.
                                                                    +1
                                                                    Ну не драматизируйте. Денег стоит установить в датацентр архив на магнитных лентах от HP. Для админов подобные задачи типа «проверить, корретно ли работает» — текучка.

                                                                    Хотя на самом деле я с вами согласен, и считаю запрет на лишний незнакомый софт мерой вполне разумной.
                                                          0
                                                          Afaik, Mondrian работает с PostgreSQL, но на практике проверять не доводилось пока, как раз размышляем в этом направлении
                                                            0
                                                            Да я тоже в его направлении смотрю. на недели буду тестить потом если понравится запилим в продакшн =)
                                                              0
                                                              Было бы интересно узнать результаты, наш продакшн будет явно еще не скоро, но хотя бы в проект записать было бы неплохо ;)
                                                          +3
                                                          Комментарии все какие злобные, это зависть?
                                                            +2
                                                            Это критика неубедительности и слабой аргументированности поста-перевода написанного «в лучших фанатских традициях» западного «маркетингового» стиля.
                                                              0
                                                              Не вижу абсолютно ничего плохого в том, чтобы обратить внимание людей на действительно хороший свободный продукт. Хотя отсутствие в оригинале и комментах к оригиналу даже ссылочки на проведённое автором сравнение Postgres и MSSQL напрягает даже меня.
                                                            +2
                                                            Ололо, а не статья. И правильно заметили выше — надо ярче указывать, что это перевод, а то переводчик может незаслуженно пострадать :)
                                                              –3
                                                              Тщательнее надо выбирать, что переводить.
                                                              +1
                                                              Отличная СУБД для больших и средних проектов. Для мелких настольных проектов я бы все-таки рекомендовал что-то «полегче»: Firebird — для многопользовательских систем(или нужен полноценный PSQL); либо SQLite если нужно «попроще да получше».
                                                              • НЛО прилетело и опубликовало эту надпись здесь
                                                                  0
                                                                  Насчет популярности Mysql относительно Postgres я думаю что тут все просто, Mysql повезло оказаться такой какая она есть в момент бума и поэтому она получила все, а postgres несмотря на свои достоинства остатки. Тут сработал принцип победитель получает все.
                                                                  Ну а уповать на рациональность выбора… ну большинству людей на это лень тяжело тратить время. Поэтому имеем что имеем. Сложно сказать сколько так будет продолжаться, но я не вижу что Postgres вытеснит Mysql в ближайшее время. Может быть что-нибудь третье?
                                                                  Хотя прогнозы такие прогнозы.
                                                                    0
                                                                    Не совсем так. У Mysql и Postgres немного различное назначение (вернее, различное назначение, исходящее из разного рыночного позиционирования).

                                                                    Собственно Mysql как изначально так и по сей день достаточно четко позиционируется как СУБД для веб-сайтов и веб приложений. Это и определяет вектор его развития, т.е. Mysql изначально не претендует на «шибко умную субд для серьезного бизнеса», поскольку вся бизнес-логика «в биосфере mysqlа» реализуется на уровне веб-приложения, а mysql-сервер занимается только быстрой обработкой select/insert/update/delete тем более большего от него и не требуют (сам своими ушами мнного раз слышал удивленные возгласы вида «а что, в мускуле есть view, не знал», «а что, в мускуле есть view, не знал», ...).

                                                                    Postgres же, позиционирует себя как «умную СУБД» и пытается лезть еще и в «нишу серьезного бизнеса»… а в этой рыночной нише Postgres тут же подвергают безжалостному сравнению с Oracle, причем, как вы понимаете, зачастую, не в пользу Postgresа.
                                                                      +2
                                                                      Ну… Oracle — штука непередаваемо большая, у них вокруг СУБД очень много чего понаверчено за десятилетия самых разных корпоративных трендов.

                                                                      Мне довелось на деле сравнивать обе БД и, как программист и как внедренец должен заметить: Oracle — БД с точки зрения программиста неплохая, но абсолютно кошмарная с точки зрения администрирования. Если админ, конечно, не сертифицированный спец исключительно по Ораклу :)

                                                                      PostgreSQL поприятней в этом смысле будет; а во многих других смыслах может как минимум равняться на корпоративного конкурента.

                                                                      Другое дело, что в корпорациях отнюдь не по объективным параметрам выбор делают. Да и существуют ли объективные параметрых сравнения столь сложных систем..?
                                                                    +2
                                                                    У mysql действительно множество недостатков, но приводить то, что отключается ОДНОЙ настройкой, в качестве основного… Автор — тролль. :)
                                                                      +1
                                                                      > Благодаря наследованию таблиц мы легко можем партиционировать таблицы

                                                                      Вот тут ребята прикололись — «партиционировать таблицы» по постгрессе ужасно неудобно, о чем неоднократно упоминали в форумах разработчиков постгресса. Как раз в коммерческих СУБД партицирование нормально сделано.
                                                                        +1
                                                                        Ну не слишком удобно но в целом секционирование в постгресе ок =)
                                                                          0
                                                                          «ok» в смысле «работает»? с этим я не спорю :-)
                                                                        +2
                                                                        Наблюдал за топиком со старта, но ответа на свой невысказанный вопрос не увидел. Теперь высказываю: всегда ли есть смысл заменять MySQL (или его форки) на PostgreSQL? Или есть какие-то формальные метрики, свидетельствующие о том, что пора переходить. Или в любом случае затраты на перевод синтаксиса будет оправданы, даже если не используются триггеры, процедуры и т. п., а Бд выступает в роли тупого хранилища?
                                                                          +1
                                                                          Если база данных используется как тупая записная книжка через ORM, то вряд ли получится заметно ощутить преимущества PostgresSQL. Если запросы довольно сложные, то стоит посмотреть на EXPLAIN и сравнить работу двух оптимизаторов. Думаю, это достаточно формальный критерий для принятия решения.
                                                                            +3
                                                                            Когда я переходил на Postgres — ощутимых завязок на синтаксис не заметил — фактически все возможности MySQL прекрасно мапятся в Postgres. Есть несколько подводных камней, они обходимы. Во времена, когда пользовался MySQL вся логика была в приложении и сам MySQL действительно был как хранилище. В Postgres'е я развернулся по возможностям, тем более и цель перед собой такую поставил — плотнее изучить возможности баз. Недавно меня пригласили в один проект, где до моего прихода использовался MySQL — ощущение, наверно, сравнимое с тем, как если бы счастливого владельца BMW посадили за руль Таврии и попросили показать класс езды. Чего только стоит некаскадность триггеров в MySQL сводящая их роль к минимальной и грозящая неприятными сюрпризами и в то же время, посмотреть на возможности ORM Zend Framework — там реализована эмуляция триггеров! То есть спрос на эту функциональность есть, если её реализовали на уровне сервера приложений, где ей совсем, казалось бы, не место. Или невозможность одновременно использовать полнотекстовый поиск и транзакции. И так — куда ни копни. Пока не пользуешься — вроде и не нужно, но когда привык — уже никуда без этих возможностей.
                                                                            0
                                                                            Я конечно понимаю, техническая статья, но про цены как-то очень вскользь упомянуто. У постгреса разумная цена администрирования и нулевая цена лицензий. И это само по себе уже агромадный плюс для небогатых контор.
                                                                            Так что зачем ее с Майкрософтом да Ораклом так упорно сравнивать? Они не конкуренты даже, т.к. на постгресе много не попилишь и экспертизу не приведешь с крутыми сертификатами (чтобы прикрыть мягкое место). Принципиально разные ниши.
                                                                              +2
                                                                              Есть и платные инкарнации Postgres с весьма вкусными плюшками и позиционирующие себя именно как конкурента «суровому энтерпрайзу»
                                                                                +1
                                                                                Справедливости ради замечу, что многие вкусные плюшки работают и с бесплатной версией, но там их нужно добавлять вручную. В этом смысле коробочное решение, да еще с поддержкой, для бизнеса гораздо «вкуснее».
                                                                                  0
                                                                                  Ну, для полноты картины можно дать ещё вот эту ссылку: PGXN — кто чувствует в себе силы контролировать дополнительные приблуды для Postgres — найдут много любопытного и полезного.
                                                                              –1
                                                                              >она легко вставит пустую строку "" в колонку с запретом на добавление пустых значений;
                                                                              Проверил на MS SQL Server 2005 и вылезла ошибка:
                                                                              «Msg 515, Level 16, State 2, Line 1
                                                                              Cannot insert the value NULL into column 'text1', table 'TestSQLBase.dbo.nullz'; column does not allow nulls. INSERT fails.
                                                                              The statement has been terminated.»
                                                                              {На видео время 01:55}
                                                                              Базу создал новую, настройки по умолчанию.
                                                                                +1
                                                                                Речь таки про «MySQL, будучи недостаточно строгой СУБД», я думаю к MS SQL эта претензия не была адресована.
                                                                                  –1
                                                                                  Аааа, пардон — перепутал два слова на М. :)
                                                                                    0
                                                                                    Значит ли это, что Microsoft SQL Server, в отличие от MySQL является продуктом, недостаточно дружелюбным к пользователю?
                                                                                      0
                                                                                      Разве это каким-то образом вытекает из вышестоящего обсуждения?
                                                                                      Я бы наверно наоборот заключил — предсказуемое и ожидаемое поведение — это более чем дружелюбное и благонамеренное отношение к пользователю.
                                                                                      А MySQL в старых версиях откровенно потакали ошибочному коду, в результате чего, мне доводилось переписывать код, прекрасно работавший в версии 3.х, но вылетавший в 5.1 с ошибкой. Кстати, там была и вышеперечисленная с кавычками — так что, похоже кое-что исправили несколько поломав совместимость.

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

                                                                                Самое читаемое