PostgreSQL vs Oracle

Сравнение с точки зрения разработчика




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

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

Около двух лет назад я перешёл из Enterprise мира в свободное плавание, где махина Oracle с её $47k за ядро — вне досягаемости.
Одним из первых freelance проектов был небольшой биллинг для суб-оператора спутниковой связи. Встал вопрос выбора РСУБД. MySQL сразу отпал по причине недоразвитости процедурного языка, выбор пал на PostgreSQL.

По мере работы над этим и следующими проектами я составлял список субъективных плюсов и минусов PostgreSQL по сравнению с Oracle с точки зрения разработчика БД. Его и представляю вашему вниманию:

PostgreSQL vs Oracle


PRO:

  • Псевдо тип serial — объединяет лучшие черты auto_increment из MySQL и sequence из Oracle.
  • Можно писать функции на чистом SQL. Например функция, состоящая из одного update c returning, возвращающая идентификатор только что добавленного значения. Позволяет избавится от явного объявления переменных, в которые выбираются данные и которые затем возвращаются в return.
  • Замечательный with в котором можно в качестве запроса использовать не только select, но и insert, update, delete returning и который можно делать рекурсивным (заменяет оракловский connect by). Кроме того заменяет собой оракловский мультитабличный insert all.
  • Generate_series вместо извращений типа select level from dual connect by level < n
  • Очень мощный механизм контроля целостности данных aka CONSTRAINTS — например EXCLUDE позволяет делать хитрые проверки ДРУГИХ строк при вставке новой (иначе пришлось бы писать триггер), REFERENCES (foreign key) c действиями при удалении или изменении записей, на которые ссылается таблица. Например constraint constname references tablename on delete cascade удалит связанные записи при удалении родительской.
  • Замечательная, но потенциально опасная (как триггеры) система правил (RULES) позволяющая подменять текст запроса отправляемый серверу. Через неё, например, реализованы VIEW.
  • Удобный раздел WHERE в определении индекса, позволяет уменьшить размер индекса не прибегая к созданию функциональных индексов и нечитабельных условий типа where decode(status,1,1,null)=1
  • LIMIT с OFFSET, позволяющие избежать геморроя с rownum, сортировкой и подзапросами.
  • Приятная документация, лишённая сухости и монструозности (но и дотошности) оракловской.

CONS:

  • Неприятные синтаксические анахронизмы, вроде необходимости ескейпить тело ХФ, например так:
    	function test() returns void as
    	$$
    	begin
    	end;
    	$$ language plpgsql;
           

    Или необходимость писать perform, чтобы вызвать процедуру по имени:
    perform my_proc(); вместо просто my_proc();
  • Убогое партиционирование через наследование таблиц и триггеры (или правила).
  • Нет механизма джобов на стороне сервера, все процессы должны быть инициированы снаружи базы (например, cron).
  • Нет packages для хранимых функций. Приходится использовать для группировки схемы, но это не совсем то.
  • Нет прекрасного хинта +parallel (выполнение запроса в несколько параллельных процессов) для ETL и прочих DWH-специфичных запросов. И вообще с многопоточностью туговато — для параллельных потоков приходится делать отдельный коннект к базе.
  • Нет MERGE.
  • Нет управления транзакциями в хранимых функциях. Может быть контроль транзакций снаружи это и более правильный подход, но мне не хватает возможности сделать явный commit или rollback прямо в ХФ.
  • Можно без ошибок скомпилить ХФ, явно ссылающуюся на несуществующие объекты. Например с выборкой из несуществующей таблицы. Об ошибке узнаем только когда выполнится этот кусок ХФ, а не на этапе компиляции, как в Oracle.


Заключение


Хорошим дополнением этому списку было бы сравнение с точки зрения DBA, но тут, как говорится, я не вполне копенгаген. Было бы очень интересно в будущем увидеть такое сравнение на Хабре.

Выводы? PostgreSQL есть куда расти, но уже сейчас при разработке проектов не сверхбольших масштабов он выглядит очень достойно рядом с чего уж таить — эталоном рынка РСУБД.
Метки:
Поделиться публикацией
Похожие публикации
Комментарии 201
  • –18
    Сразу оговорюсь — я не имею ничего против размещения части бизнес логики в хранимых функциях, если это предусмотрено в архитектуре системы и оправдано по ряду практических соображений, которые выходят за рамки этой статьи.

    когда вы наконец поймёте что «размещения части бизнес логики в хранимых функциях» это калька с подхода на императивных языках типа Java и C++.

    В реляционных базах данных сама структура таблиц уже является описанием бизнес-логики.
    • +17
      В реляционных базах данных сама структура таблиц уже является описанием бизнес-логики.


      О_о
      Структура таблиц описывает только способ хранения данных. А бизнес-логика — это условия, ветвления, переходы, которые позволяют реализовать процесс, не описать.
      • –1
        ну, судя по минусам это действительно слишком сложно для большинства.

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

        Структура таблиц и связей в реляционных базах является описанием самих данных а также способом работы с ними.

        Простейший пример:

        таблица Отделы и таблица Сотрудники имеющая ссылку на отдел. Такая структура однозначно описывает бизнес-правило «каждый сотрудник должен принадлежать какому-то отделу». Причём SQL-сервер будет отслеживать эту связь и никаким способом, ни на каком языке программирования не удастся засунуть в базу данные нарушающие это правило.

        Ну и т.д.
        • +5
          Бизнес-логика не должна быть завязана на способ хранения.
          Я могу половину данных держать в MongoDB, а другую половину в PostgreSQL, и в один прекрасный момент, полностью перейти либо на первое, либо на второе.
          В реализации бизнес-логики, я не смотрю в сторону БД, а оперирую свойствами объектов.

          Если у вас в сознании частью бизнес-логики является система хранения данных, то у меня для вас плохие новости, вы не понимаете, что такое абстрагирование.
          • +6
            >Бизнес-логика не должна быть завязана на способ хранения.
            >Я могу половину данных держать в MongoDB, а другую половину в PostgreSQL

            Даже если держат данные в нескольких oracle БД — это уже гарантия поиметь массу неприятностей из-за распределенности.
            Есть такая штука — ACID-тест для БД. Если Вы собираетесь хранить данные в нескольких БД, то о целостности данных можно смело забыть!
            • 0
              В том случае, если целостность необходима на уровне БД.

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

              Впрочем, любая масштабируемость — это уже дорого )
              • 0
                Если целостность расходится -то это уже не целостность, imho :)
              • 0
                Для одинаковых данных верно. Для слабосвязанных — нет. Например, логи работы могут всегда лежать отдельно, но использоваться для формирования общих отчетов.
                • +2
                  ACID ничто иное как илюзия. CAP теорема работает даже для одного узла. В любом компъютере есть процессор, память, кеши разные, постоянная память. И пусть доступность или согласованость теряется на меньшие кванты времени чем при распределенной системе, но потери есть. А теперь усложним задачу. Скажите хорошему банку что базу хранить будем в одном экземпляре и в одной локации. Банк не пройдет судить, а вас отправят в сад. Добавляем второй узел и об ACID забываем. Amazon как-то столько лет живет без ACID?
                  • –1
                    ACID для БД не иллюзия. Наборот, БД без ACID — это не БД :)
                    Суть в том, что невозможно увидеть эту рассогласованость. Максимум, что может быть — потеря незакомиченных транзакций.
                    Разные локации используются не только для распределения нагрузки, а в основном для резервирования, что организуется за счет возможностей репликации на уровне дисковых массивов или возможностей репликации самой БД, что обеспечивает опять же целостность за исключением незакомиченных транзакций.
                    Про амазон ничего не скажу, не в курсе их архитектуры — я 14 лет oracle dba больших БД.
                    • 0
                      Если вы не видите рассогласованости это не значит что ее нет. Вы просто теряете в доступности и уже есть множество приложений где эти потери недопустимы и 100-мс это непозволительно долго. Amazon Dynamo DB позволяет милисекундные задержки. Не знаю как в Оракле но вчера проскакивала статья о T -SQL и специальной опции no lock которая позволяет увидеть рассогласованость, но увеличить доступность.
                      Теореме CAP уже более 10 лет и пока не нашлось способных ее опровергнуть. Из 3-х свойств одновременно возможны только 2.
                      14-лет большой срок, за это время успели сменился 2-3 технологические эры, стоит расширять свой кругозор.
                      • 0
                        Да, теперь понятно, почему каждый по-своему прав.
                        В рамках BASE-архтектуры такое возможно, когда скорость важна.
                        Для банков, мобильных операторов и т.п — только ACID — жертвуем скоростью доступа для обеспечения консистентности.
                  • 0
                    а при чем в данном разрезе целостность?
                    мы про бизнес-логику говорим. А уж для чего понадобилось разделять данные по различным БД это дело десятое.

                    • 0
                      Например, бизнес логика — вставить запись в таблицу платежей (insert) и обновить баланс клиента (update), зафиксировать изменения (commit).
                      Теперь поясните, если таблицы платежей и балансы лежат в разных БД — как Вы сможете гарантировать, во-первых, что не окажется зафиксирован только insert или только update в случае сбоев, во-вторых, при нормальной работе другие процессы, читающие данные по этому клиенту не получат расхождение в данных платежей и баланса по клиенту?
                      • 0
                        вы не поняли.
                        зачем в данном ключе вообще разговаривать о целостности?
                        с тем же успехом мы сейчас можем начать говорить о погоде, но при чем тут погода?!
                        я же говорю о том, что бизнес-логика это совершенно другой уровень абстракции.
                        • 0
                          А бизнес логика при том, что она должна быть обеспечена некими механизмами, которые гарантировано работают.
                          Вот, Вы готовы держать платежи и балансы в разных БД, а я Вам объясняю, почему этого делать нельзя :)
                          • +1
                            При чем способы хранения данных к бизнес-логике? Я могу хранить платежи и балансы как угодно, и это никак не повлияет на бизнес-логику.
                            • 0
                              Хорошо. Например Вы — банк, у Вас есть входящий баланс счета на дату, проводки по нему и исходящий баланс. То, что появление новой проводки изменяет баланс — это бизнес-логика или нет?
                              • 0
                                бизнес-логика
                                • 0
                                  Вот, хорошо. Так речь о том, что если проводки и баланс лежат в разных БД, то вы не сможете обеспечить между ними соотвествие — может пропасть одно из двух полностью, либо в выписке по счету в определенный момент времени у вас не сойдется начальный баланс, сумму по проводкам и конечный баланс.
                                  Не знаю, как еще доступнее объяснить :)
                                  • +1
                                    Вы смотрите на БД как на неотъемлемую часть процесса бизнес-логики. Я смотрю на БД как на поставщика данных. Не более того.
                                    • 0
                                      Я Вам объяснил, почему БД является неотъемлимой частью.
                                      • –1
                                        Почему вы не можете абстрагироваться от метода хранения данных?
                                        Нам не важно как хранятся наши данные.
                                        В БД они, в файлах или в облаке.
                                        Для бизнес-логики это не важно. При её проектировании мы оперируем сущностями. А как сущности хранят данные — это уже не важно при проектировке. За это отвечает ORM.
                                        • 0
                                          Да ради бога, абстрагируйтесь на здоровье.
                                          Только не надо опускаться до уровня БД и рассказывать, что данные могут лежать по разным БД, а то ведь вам поверят, а потом расхлебывай :)
                                          • –1
                                            Данные могут лежать по разным БД.
                                            Особенно когда Insert идет в одну базу, а Read из другой.
                                            Ваш комментарий был совсем не к месту, пора бы вам это признать.
                                        • 0
                                          Советую ознакомится вот с этим, что бы понять что такое абстракция.
                                          • 0
                                            Ваша абстракция не проходит проверку ACID

                                            Следовательно даже если она ничего не нарушает, в критических приложениях применяться не может.

                                            Вы все еще хотите абсолютно абстрагироваться от метода хранения данных?
                                            • –1
                                              >Ваша абстракция не проходит проверку ACID
                                              Что за бред вы несете?
                                              • 0
                                                Да не бредовее вашего:
                                                «и в один прекрасный момент, полностью перейти либо на первое, либо на второе.»

                                                Как только поработаете с чем-то сложнее сайта-визитки или что вы там делаете?
                                                Так сразу и поймете насколько платформозависимы конкретные решения в более менее сложных системах и как проблематично найти тот самый «прекрасный момент», когда вы сможете позволить себе все поменять.
                                                • 0
                                                  серьёзно?
                                                  хм, а с чего вы взяли, что я не работал с проектами сложнее сайта-визитки? -))
                                                  • 0
                                                    А я там же сразу и написал с чего я взял.
                                                    • 0
                                                      Ну, что я могу сказать вам. Судя по всему, вы работали в проекте(-ах) в которых была не достаточно хорошо продумана архитектура.
                                                      • 0
                                                        А все потому, что разрабатывали именно с точки зрения, что БД это часть бизнес-логики.
                                                        Одна из крупнейших ошибок при разработке.
                                                        • 0
                                                          Это не ошибка. Эта логика проповедовалась на протяжении не одного десятка лет. В ней есть свой смысл и свои позитивные стороны. Но, как всегда, люди начали применять не тот инструмент не там.
                                                          • 0
                                                            Да, наверное я не правильно выразился.
                                                            Это старый подход к разработке, который решал задачи с другими предпосылками(например с точки зрения экономия памяти)

                                                            А в данный момент, этот подход устарел.
                                                          • –1
                                                            Вы просто очень мало работали.

                                                            Независимо от качества продуманности архитектуры, логика зависит от того какие данные.

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

                                                            P.S. Чтобы уж совсем ясно было.
                                                            Действительным прорывом была машина тьюринга. А дальше с разной успешностью люди пытались от нее отойти.
                                                            К примеру, посмотрите на jvm. Созданная якобы для переносимости, но 32бит приложение java не может работать в 64бит JRE.
                                                            • 0
                                                              Извините конечно, но меня забавляют фразы про мой опыт и длительность работы в сфере разработки. Вы же обо мне ничего не знаете :)

                                                              Я ведь тоже могу заявить, что то в этом духе, однако не позволяю себе этого, т.к. это не конструктивно и не аргументированно.

                                                              Могу лишь спросить вас(для того что бы составить мнение о ваших знаниях), что значит абстракция и какой процесс на ваш взгляд, при разработке наиболее важен: синтез или декомпозиция?
                                                              • 0
                                                                К примеру, посмотрите на jvm. Созданная якобы для переносимости, но 32бит приложение java не может работать в 64бит JRE.

                                                                Вы это сейчас серьезно? Все прекрасно работает, я вам скажу даже больше свободно переносится не только между x86 и x86-64, но и на другие архитектуры, например SPARC, zSeries и т.д.
                                                                • 0
                                                                  Что-то я даже засомневался…
                                                                  Ан нет…

                                                                  Одна из IDE отказалась запускаться на этом JRE

                                                                  java version «1.7.0_05»
                                                                  Java(TM) SE Runtime Environment (build 1.7.0_05-b06)
                                                                  Java HotSpot(TM) 64-Bit Server VM (build 23.1-b03, mixed mode)

                                                                  А на этом заработало

                                                                  java version «1.6.0_31»
                                                                  Java(TM) SE Runtime Environment (build 1.6.0_31-b05)
                                                                  Java HotSpot(TM) Client VM (build 20.6-b01, mixed mode)

                                                                  Ну, а это вообще феерично.
                                                                  gyazo.com/1cfbda5ea0978de80b211cee68b1fd0b
                                                                  Верно?
                                                                  • 0
                                                                    Да Вы конкретней, не стесняйтесь сказать какая IDE и т.д., ни разу не сталкивался с подобной проблемой. Может быть какие пруфлинки найдутся, обсуждения на stackoverflow?
                                                                    Что фееричного на скриншоте тоже совсем непонятно, Вы бы хоть удосужились пояснить.
                                                                    • 0
                                                                      IDE? Да можете проверить на Eclipse, Netbeans, Idea.
                                                                      И ниже все правильно и корректно расписали, именно из-за расширения gui и есть проблемы.

                                                                      Про фееричность на скриншоте…
                                                                      Там же желтым выделено. Вы прочитать не удосужились?

                                                                      И прямым текстом сообщают, что если используется и 32 и 64 бит приложение, то вам «нужно» поставить и 32 и 64 бит JRE чтобы ваш ява-плагин работал в обоих случаях.

                                                                      Кроссплатформенность во весь рост…
                                                                      • 0
                                                                        Чтобы одно не Java приложение могло подружиться с другим не Java приложением они должны иметь одинаковую разрядность.
                                                                    • +1
                                                                      Ну то что IDE не запускается еще не означает что дело в java-машине. Все эти IDE как правило используют native — расширения, вместо swing или awt в них используют swt, а это не чистая java.
                                                                      Тот же eclipse 32 разрядный не заработает на 64 разрядной jvm, а все потому, что данная IDE включает в себя около 50 dll (windows версия), скомпилированных либо под 32 разряда, либо под 64. Разрядность этих библиотек должна соответствовать разрядности jvm.
                                                                      Но вот любая программа, использующая исключительно jdk, будет работать как на 32 так и на 64 разрядной jvm независимо от того, на какой из них она скомпилирована
                                                                      • –1
                                                                        Вот вы сами и ответили нашему юному апологету абстракции.

                                                                        Чистая абстракция нежизнеспособна. Рабочие решения платформозависимы.

                                                                        А вам SowingSadness, предлагаю вернуться к разговору, когда вы получите более серьезный опыт.
                                        • 0
                                          Конечно же бизнес-логика. Я знаю к чему вы будете сейчас клонить, что если хранить в разных базах, то обновление одного параметра приведет к неконсистентности данных. На что я вам резонно возражу, что если все «кешировать» в промежуточном «оперативном» слое, то способ хранения этих данных перестает играть важную роль. Хранение есть хранение. Тенденция последних лет двадцати была такова, что все стремились переложить бизнес-логику на БД, хотя база — совершенно не подходящее место для этого. И были воспитаны поколения людей, которые мыслят подобным образом. Это не плохо, это один из путей развития, но он привел в тупик многие компании.
                                          • 0
                                            Вопрос, сможет ли этот промежуточный кэш пройти тот же ACID-тест?
                                            Про тупик для многих компаний было бы интересно почитать.
                                            Самые объемные и нагруженные БД, имхо, моибльных операторов — вполне себе живут в OLTP части на одном сервере, в части DWH возможен RAC.
                                            • 0
                                              А почему не сможет?
                                              • 0
                                                Привидите пример такой системы.
                                                • 0
                                                  Ответьте сначала на мой вопрос.
                                                  • 0
                                                    Хорошо. Очевидно, что необходимо наличие энерго-независимой памяти.
                                                    • +1
                                                      По вашей логике только БД является единственно правильным и единственным местом хранения данных, чтобы поддерживать консистентность и исключительность данных. Логика имеет место быть. Но даже у БД есть слабое место, если по каким-то причинам redo-лог не был записан, то транзакция не свершится.

                                                      • 0
                                                        Да, redo- самое слабое место. Именно поэтому до сих пор несмотря на наличие всяческих рэйдов и репликаций на уровне массивов oracle рекомендует создавать как минимум два лога в каждой группе :)
                                                        • 0
                                                          Аналогичную практику по redo-логам можно применять и на уровне «программной прослойки». Другими словами, поддержание данных в консистентном состоянии — задача более высокоуровневая, чем просто хранение.
                                                          • 0
                                                            Согласен, но зачем изобретать велосипед? Задача же не такая уж и тривиальная.
                                                            • 0
                                                              Чтобы не быть привязаным к одной базе.
                                                              • 0
                                                                так все-тиаки существует реальный продукт, который это обеспечивает? :)
                                                                • +1
                                                                  Тот же Facebook подойдет?
                                                  • +1
                                                    Ну развели флейм.
                                                    В интерпрайзе такие системы и проблемы сплошь и рядом, и ничего, проблемы целостности решаются. Не обязательно на «аппаратном» уровне, если это невозможно, то в ход идут административные, организационные и прочие решения.
                                                    Например, любая карточная система: там в любой транзакции не то что базы разные, а целые системы, как минимум банк плательщика — карточная система — банк продавца. И ничего, платежи как-то ходят, и товары покупаются )
                                                    • –1
                                                      В приципе — да, но это же не от хорошей жизни, а резальтат исторически сложивихся обстоятельств. Насколько было бы проще, если бы все жило в одной БД :)
                                                      Так что для нового цельного проекта изначально стараться распределить даные по разным БД — это нонсенс.
                                        • 0
                                          Вот, Вы готовы держать платежи и балансы в разных БД, а я Вам объясняю, почему этого делать нельзя

                                          en.wikipedia.org/wiki/Distributed_transaction
                                          • –1
                                            В теории — да, на практике это редко используется, imho, и обеспечивает изрядный гемор dba.
                                        • 0
                                          Бизнес правило: при нажатии купить с счёта клиента списываются деньги, на ваш поступают, операции должны пройти атомарно.
                                          Реализовать данное правило без введения понятия согласованости невозможно.
                                        • +1
                                          Вы оперируете терминами не бизнес-логики, а логики хранения. В терминах бизнес-логики задача звучит типа «провести платеж (обновив баланс)».
                                  • +6
                                    Лично я минусов не ставил. Бизнес-логика — это абстрактное понятие, оно не привязано ни к какому языку программирования. Привязка сотрудника к отделу не является бизнес-логикой, это структурная модель. А вот правила перехода сотрудника из отдела к отделу — вот это уже бизнес-логика.
                                    • –7
                                      ну как-то же в коде описывается проверка правильности перехода сотрудников из отдела в отдел. Точно также эти правила могут быть описаны в структуре данных.

                                      Именно для этого и существует такое понятие как «нормализация». И именно поэтому существует Оракл и Постгрес.
                                      • +5
                                        Проверка правильности заложена в бизнес-логике. Но эту проверку невозможно рассмотреть из структуры данных. К примеру, у вас связь один ко многим для отдела и его работников. Исходя из структуры таблиц можно легко сделать вывод, что можно всех работников сделать уборщиками или директорами. Это позволяет структура хранения данных. Но на практике есть правила, которые формируются за пределами БД.

                                        Нормализация — это естественное желание сделать структуру хранения данных как можно более универсальной, готовой к любым изменениям и расширениям. Но за универсальность приходится платить высокое пенальти по скорости
                                        • –1
                                          ох… Точно так же как на С++ больше условий требует больше кода, так и в бд больше условий требует более сложную схему.

                                          Логично?

                                          По проблемам производительности на нормализованных данных — можно провести тест и всё выяснить. Разумеется тест должен готовить человек который понимает что делает.
                                        • +4
                                          Покажите мне большую и полностью нормализованную базу… и я сразу скажу, что у неё никогда не было проблем с работой под нагрузкой.

                                          Стоит её загрузить и закормить — они появятся и, скорее всего будут решены денормализацией и деструктуризацией.

                                          Хозяйке на заметку, кэширование — это тоже в некотором роде денормализацияю
                                          • 0
                                            И в Oracle денормализация реализована из коробки. Явно их задолбали клиенты этим требованием.
                                            • 0
                                              Это Вы о чём именно говорили? Где она там?
                                              • 0
                                                • 0
                                                  Поясните, пожалуйста, как они связаны с денормализацией
                                                  • +1
                                                    Денормализация — процесс, обратный нормализации. Превращение хранения данных из нормальной формы, где, в идеале, все данные хранятся в единственном числе, в вид, когда данные могут храниться в готовыми к употреблению, в том числе в виде склеек. MV позволяет денормализировать данные, обновлять их при изменении исходных данных.
                                                    • 0
                                                      Понятно, спасибо.

                                                      К сожалению, как средство денормализации материализованные вьюхи дороговаты. Если нужно продублировать одну колонку, дешевле добавить её напрямую и поддерживать программно, чем делать нормализованную табличку без этой колонки и рядом строить вьюху, содержащую её полную копию с нужным дублем колонки из другой таблицы…
                                                      • 0
                                                        Как раз для дублирования колонки материализованая вьюха и подходит лучше всего. Ведь вас никто не ограничивает создавать две или более вьюх. Мало того, программно поддерживать — это снова же часть сути MV. Количество телодвижений при «программной поддержке» и MV одинаковое, а профита от последнего варианта — в разы больше.
                                                        • 0
                                                          Я ж говорю, она все данные дублирурует, а ради одной колонки это слишком жирно…
                                                          • 0
                                                            В чем жирность? Я не могу понять, что конкретно вас беспокоит? Вы экономите на спичках?
                                      • +1
                                        таблица Отделы и таблица Сотрудники имеющая ссылку на отдел. Такая структура однозначно описывает бизнес-правило «каждый сотрудник должен принадлежать какому-то отделу».

                                        А как насчет, скажем, бизнес-правила «В отдел N с такого-то числа запрещается вводить новых сотрудников»? Сможете описать эту бизнес-логику через структуру таблиц (см. ваше «в реляционных базах данных сама структура таблиц уже является описанием бизнес-логики»)?
                                        • 0
                                          В том-то и дело что сможет.

                                          Вы тут минусите не мне, а ораклу, за который платят "$47k за ядро" и оно стоит тех денег. Иначе б никто не покупал.
                                          • 0
                                            «оно стоит тех денег» — очень общее понятие, включает в себя не только технические возможности (о которых говорится в статье), но и всякие другие. Например orablog.ru/archives/category/oracle/jdedwards

                                            По-хорошему, конечно нужно считать расходы тщательно, прежде чем покупать.
                                            • +1
                                              Т.е. Оракл сможет? Только на структурах — без триггеров? А что-нибудь посложнее? Типа «Все сотрудники отделов, принесших доход в предыщем месяце более N рублей, 10 числа следующего месяца получают по K% премии»?

                                              P.S. Я минусить в принципе не могу (см. карму).
                                              • –2
                                                Оракл много чего может. Как и Постгрес.

                                                Но вопрос некорректен. Надо «может ли это быть задано структурой и связями данных?». Ответ — да, может.
                                                • 0
                                                  1. Чем некорректен?
                                                  2. Напомню, что раньше вы говорили лишь о структурах данных (см. ваше «в реляционных базах данных сама структура таблиц уже является описанием бизнес-логики»). Теперь у вас появилось дополнительное понятие — «связи данных». Что вы в него включаете? Primary/foreign keys или вообще любой код на сервере, используемый в операциях над данными?
                                                  • 0
                                                    1. Оракл это только один из представителей SQL-серверов. Поэтому спрашивать только про оракл некорректно — все могут, не только он.

                                                    2. Реляционная алгебра (основа серверов и языка SQL ) оперирует аттрибутами, кортежами и отношениями. В просторечье это поля, таблицы и связи.
                                                    • 0
                                                      Я знаю, что такое реляционная алгебра — не надо мне объяснять.
                                                      Лучше бы объяснили, как в SQL команды определения структур данных (напомню еще раз — вы говорили о чудесной возможности описать бизнес-логику структурами таблиц) помогут вам решить упомянутую мной задачу («Все сотрудники отделов, принесших доход в предыщем месяце более N рублей, 10 числа следующего месяца получают по K% премии»).

                                                      И еще: код, который вам придется для этого написать, не имеет никакого отношения к термину «отношения» («в просторечье связи») в реляционной алгебре (пардон за тавтологию).
                                                      • –4
                                                        Объяснить? Да легко.

                                                        Но не в этой теме.

                                                        Кто хочет может создать топик вроде «Ущербность реляционных баз данных» и там выдвинуть тезисы о невозможности решить «упомянутую задачу» средствами SQL. Привести там примеры решения этой же задачи на любом языке программирования и удивиться элегантности решения её же средствами SQL.

                                                        Формат Хабрабра таков что любое мнение не совпадающее с любыми, даже самыми дилетантскими мифами, ведёт к минусованию. В таком формате сложно приводить какие-то доводы. Метание бисера напоминает.
                                                        • 0
                                                          Дайте угадаю, кто-то создаст отдельный вьюв =) но это однако бред.
                                                          • 0
                                                            ути-пути) реляционная модель — суть логическая модель — факт. только бизнес-логика здесь не при чем ваще. :)
                                                          • 0
                                                            «отношения» («в просторечье связи») в реляционной алгебре
                                                            мм… «отношения» в просторечье это «множества». а связи между ними определяются операторами, которые используются в выражении.
                                          • +1
                                            Вы путаете предметную область и бизнес-логику.

                                            Структура таблиц является описанием терминов, понятий и отношений предметной области. А бизнес-логика описывает алгоритмы, процессы, правила предметной области, в применении к понятиям и отношениям предметной области.

                                            Бизнес-логика может быт реализована, например, на PHP/Python/Ruby/Java/PLSQL/whatever. А таблицы описаны и храниться в RDBMS. Или в каком-нибудь NoSQL (тут «No» в значении «No», а не «Not Only»). Языком общения этих двух штук является SQL или какой-нибудь иной самодельный API.
                                          • +2
                                            Еще пара плюсов в сторону PostgreSQL: http://habrahabr.ru/post/45475/ и http://wiki.postgresql.org/wiki/PGQ_Tutorial
                                            • +11
                                              Пару лет работаю с PostgreSQL. Нравится и стабильность и возможности СУБД.
                                              • 0
                                                А никто случаем с Oracle на MS SQL не переходил?
                                                Что можно сказать про T-SQL?
                                                • +1
                                                  Вам будет не хватать произвольной конвертации значений по маске (в стиле to_date(), to_char()) и подобных мелочей. А в целом нормально.
                                                  • +1
                                                    Я сейчас перехожу. Могу сказать что будет нехватать очень много чего.

                                                    Начиная прямо с типа tinyint, который можно правда заменить доменом.

                                                    Еще было удивительно поведение unique index с null полями. В MS SQL это настраивается c помощью ANSI NULLS и по умолчанию не соответствует стандарту, в постгре же по стандарту и не настраивается. По стандарту null != null и следовательно если в наборе полей включенных в unique индекс есть хоть 1 null то вы можете вставить сколько угодно таких наборов.

                                                    Механизм хранения больших двоичных данных тоже… не такой как везде.

                                                    Вообще много разных фокусов, могу если будет много желающих статью написать. Но в целом жить можно.
                                                    • +1
                                                      А соврал вам, с утра что-то невнимательно прочитал. Это я написал с MS SQL на постгре.
                                                      • 0
                                                        а можете пояснить почему пришлось переходить? Чем MS SQL не устраивал?
                                                  • +3
                                                    Пакетов в PostgreSQL очень не хватает.
                                                    • 0
                                                      А что это такое?
                                                      • 0
                                                        Погуглил. Очень похожи на extension в postgres.
                                                      • +5
                                                        А кто-нибудь работал с коммерческим Postgres (ака EnterpriseDB Advanced Server )? Судя по рекламе там очень много вкусностей именно для переходящих с Oracle (планировщик задач в БД, нормальное секционирование таблиц, пакеты для процедур и т.д.), насколько не врет реклама?
                                                        • +2
                                                          В процедурах на PL/pgSQL есть явное управление транзакциями (через исключения). Путем организации блока begin/exception/end можно создавать подтранзакции, и откатывать или коммитить их по отдельности.
                                                          • 0
                                                            Коммитить-то как раз нельзя (в том смысле, чтобы гарантировать фиксацию изменений в данных до выхода из функции). Вообще за явный коммит внутри процедуры надо в большинстве случаев рвать пинцетом волосы в межягодичной впадине.
                                                            • 0
                                                              Да, коммит родительской транзакции из процедуры, выполняющейся в ее же рамках, разумеется, невозможен.
                                                              Если хочется из функции открывать новые top-level транзакции, то инструменты вроде plproxy (используется autocommit, все очень удобно но явного управления транзакцией нет) или dblink (не очень удобно, но можно явно начинать/коммитить/откатывать транзакцию) в помощь.
                                                          • 0
                                                            Автор, рекомендую для небольших проектов посмотреть еще в сторону Firebird. По развитости SQL и PSQL лишь немного уступает, но зато гораздо легче сама по себе. + Есть локальный embedded-вариант в виде DLL но с абсолютно теми же возможностями что и server.
                                                            • +3
                                                              Стабильная?
                                                              • 0
                                                                Вполне
                                                                • 0
                                                                  Какие плюшки?
                                                                    • +1
                                                                      в нем конечно нет пакетов, партиционирования и пр. но то что заявлено работает и работает предсказуемо.
                                                                      • 0
                                                                        Мне кажется, основной плюс FB — минимальные затраты на администрирование и возможность работы на чем угодно.
                                                                        Делает программу, которая должна быть установлена на другом конце страны, неизвестно кем и на каком оборудовании — выбирайте FB. Если же это высоконагруженный сервер приложений, работающий у вас под присмотром, то Postgre SQL, хотя, конечно, в таких случаях факторов влияющих на выбор может быть много.
                                                                        • 0
                                                                          В качестве легковестного SQL для программы, которая будет установлена фиг знает где, можно использовать и SQLite.
                                                                          • 0
                                                                            SQLite — жуткий тормоз на запись. Был по крайней мере пару лет назад. Сейчас может поправили.
                                                                            • +1
                                                                              Мягко говоря, странное заявление.

                                                                              Возможно связано с непониманием механизма транзакций SQLite?..

                                                                              • +1
                                                                                Кстати, да. Я когда проверял намеренно вставлял каждую строку в отдельной транзакции. Но в тех же условиях Postgres был на примерно два порядка быстрее.
                                                                                • 0
                                                                                  Postgres не был «в тех же условиях».

                                                                                  SQLIte гарантирует, что после возврата из вызова (в котором фиксируется транзакция и при использовании синхронизации FULL) можно выдернуть шнур из питания и данные не пропадут.

                                                                                  Postgres же «делает вид», что данные зафиксированы на диске. Не знаю подробностей, но думаю он использует что-то подобное MS SQL с отложенной фиксацией транзакции на диске.

                                                                                  Т.е. если после возврата вызова (для Postgres) выдернуть шнур — данные пропадут.

                                                                                  • 0
                                                                                    Postgres же «делает вид», что данные зафиксированы на диске.
                                                                                    Это как настроишь. По-умолчанию делает fsync журналу при каждом COMMIT, но можно настроить и на отложенный сброс.
                                                                                    • 0
                                                                                      Я уже условий в которых я тестировал не помню, давно это было, посему спорить не буду.
                                                                              • 0
                                                                                SQLite отличная штука, для однопользовательских и действительно простых задач. Офигенно компактная и быстрая. У Firebird сегмент более сложных многопользовательских приложений, но не корпоративного сегмента, а попроще. Фактически это разные весовые категории.

                                                                                • +1
                                                                                  Я очень плотно использую Sqlite в «непростых» задачах :)

                                                                                  Надо бы написать статью.

                                                                                  SQLite вполне годится и для больших проектов.
                                                                                  • 0
                                                                                    Вполне, если бизнес-логику возможно утащить на клиент не потеряв производительности. А проект многопользовательский? Чем обусловлен выбор именно SQLite?
                                                                                    • 0
                                                                                      Хммм… Тем, что аналогов нету?

                                                                                      Проект — коммутация сообщений, сервер с набором множества различных каналов и очередей сообщений.
                                                                                • 0
                                                                                  В качестве легковестного SQL для программы, которая будет установлена фиг знает где, можно использовать и SQLite.

                                                                                  Тоже вариант.
                                                                                  FB в качестве встроенного сервера выбирают в основном те, кто работал с обычной версией. У FB Embedded есть один весомый плюс — он ничем не отличается от обычного и одно и тоже приложение может работать как с локальной БД так и с удаленной.
                                                                              • +1
                                                                                Да, к плюшкам можно отнести IBExpert — IDE для Firebird и Interbase. Это пожалуй лучшая IDE среди вообще всех IDE для РСУБД. И она бесплатна для exUSSR.
                                                                          • +1
                                                                            Судя по тому, что автор переходит с Oracle вряд ли речь идет о домашней странице Васи Пупкина. Для небольших проектов необходимости писать хранимые процедуры как правило нет.
                                                                            • 0
                                                                              Ну как небольшие, я занимался проектом около полумиллиона строк, там FB был именно тем что нужно, ХП использовались очень активно. Дело в том, что FB гораздо менее требователен к ресурсам на малых объемах данных, что очень важно для слабого оборудования (POS-терминалы, например).
                                                                              • 0
                                                                                А еще у fb помню были мелкие приятные плюшки вроде селекта из функции без оракловой монстроидальности с пайплайном и кастингом.
                                                                                • 0
                                                                                  Совершенно верно, SELECT some_field1… some_field_N FROM some_procedure(....) where… короче полная эмуляция таблицы. Можно сортировать, группировать, джойнить
                                                                              • 0
                                                                                никто не советовал FB для домашней страницы, у не него другая ниша.
                                                                            • –1
                                                                              Заходя в топик, прихватил кусок арматуры. Оказалось, не нужен.
                                                                              • +1
                                                                                В чем же заключается «недоразвитости процедурного языка» в mysql? Не холивара ради, а в целях расширения кругозора?
                                                                                • 0
                                                                                  К примеру нет raise вообще. Дополнительно так-как требуется совместимость с MyISAM блокировки на выполнение процедур глобальные.
                                                                                • –1
                                                                                  Очень интересная дискуссия относительно бизнес логики. Расскажу два случая.

                                                                                  Я работал в ВЦ ГТК (Таможенное управление) и мы внедряли систему АИСТ (автоматизированная система таможни), наш исполнитель начал разрабатывать систему АИСТ на Ms SQL Server, как временное решение, так как для него лицензионный Oracle был дорог. Хочу пояснить, что в соответствии с регламетом Гостехкомиссии, все данные должны были хранится в Oracle, на то время 2000г, Oracle во время подсуетились, и только эта РСБД прошла Сертификацию и была рекомендована для внедрения в Госорганах.
                                                                                  Так вот, исполнитель начал разработку под SQL сервер и обещал, что как только они приобретут лицензию на Оракл, то быстро переведут систему на другую СУБД. Прошло три года, наступил этап передачи Программного обеспечения. К этому времени оказалось, что написано более 3000 ХП и для перевода на Оракл понадобится еще пол года разработки. Так что потом пришлось писать кучу писем на разрешение использовать Ms SQL.

                                                                                  Вторая история: когда-то я работал я в tradebox.ru
                                                                                  Наш бывший архитектор, до этого разрабатывал Interprise решения на базе Оракл, и решил перенести эту архитектуру на небольшой WEB проект на базе MySQL.
                                                                                  Большую часть бизнес логики решил реализовать на ХП.
                                                                                  Мы долго искали SQL программиста, часть хранимок писал он сам. В итоге разработка из 6-9 мес затянулась более чем на год. Было написано более 50 ХП.
                                                                                  В результате оказалось, что MySQL не справляется с бизнес логикой, постоянно возниакют
                                                                                  deadlockи, очереди необработанных сообщений стали расти. В общем, проект был загублен плохой архитектурой…
                                                                                  • 0
                                                                                    а есть положительный пример перевода системы такого же размера как АИСТ? Отрицательных много можно привести на разных технологиях, и с базами данных и без них.

                                                                                    Положительных чёто мало. Причём даже если всё принято и деньги заплачены.
                                                                                    • +3
                                                                                      Большую часть бизнес логики решил реализовать на ХП.

                                                                                      В MySQL? Наркоманы?
                                                                                      • +2
                                                                                        Вы зря так категорично относитесь к mysql. Если сравнить постгрес и мускль, то можно заметить, что и там, и там есть как плюсы, так и минусы. И по их количеству паритет. Ведь не зря его использует такое кол-во людей. И facebook, вконтакте начинали (и сейчас продолжают использовать, но не в полной мере) именно с mysql. Либо все вокруг дураки и не знают что есть куда лучший инструмент — постгрес, либо у вас предвзятое отношение. Я сейчас работаю в организации, где основная база мускуль. Нагрузка на нее создается приличная. Используется секционирование, часть логики (работа с деньгами, например) написана на хп. Все кешируется в мемкеш + грамотное использование индексов. Все это дает приличный запас прочности проекту. Поэтому дело не в инструменте, а в руках, его использующих.
                                                                                        • 0
                                                                                          Вы зря так категорично относитесь к mysql. Если сравнить постгрес и мускль, то можно заметить, что и там, и там есть как плюсы, так и минусы. И по их количеству паритет.

                                                                                          Я работал и с тем и тем. И если у меня есть выбор между СУБД я всегда выберу PostgreSQL. В MySQL очень много всяких раздражающих факторов. Один из главных это глобальные блокировки и адово низкая производительность при большом числе параллельной записи.

                                                                                          Ведь не зря его использует такое кол-во людей.

                                                                                          Как правило эти люди или не видели других СУБД или ее выбрали за них.

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

                                                                                          Увы не показатель. С MySQL сильнее приходится прыгать с бубном и быть существенно более аккуратным при написании запросов.

                                                                                          Используется секционирование, часть логики (работа с деньгами, например) написана на хп.

                                                                                          Ключевой момент во первых часть логики. Во вторых я не думаю что у вас хранимка работает долго. И у вас явно нет длинных транзакций.

                                                                                          Все кешируется в мемкеш + грамотное использование индексов.

                                                                                          Если у вас так все хорошо работает зачем вам memcache?

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

                                                                                          Вот возьмите и попробуйте тоже самое сделать на PostgreSQL и вы удивитесь насколько там многие вещи сделаны удобнее и лучше.
                                                                                          • 0
                                                                                            Я тоже работал и с тем и другим. Да, согласен, что где-то приходится прыгать с бубном, но разве в постгресе не так?
                                                                                            1. Адово низкая производительность? Что для Вас адово низкая? Не замечал такого. Может просто не стоит увешивать таблицу, в которую много пишут огромным количеством индексов? Не знаю, может еще какие-то причины у вас были.
                                                                                            2. Очень сильно сомневаюсь, но утверждать не буду
                                                                                            3. Тоже работал с постгресом и не скажу, что танцев было меньше
                                                                                            4. Я не считаю необходимым переносить всю логику в базу. Здесь уже куча подобных комментов заминусовали, но я с ними соглашусь. База не должна быть нагружена логикой. В первую очередь это хранилище данных. По поводу долгих хранимок согласен. Но опять же, субд — не сервер для выполнения нереальных обработок, стоит как-то оптимизировать.
                                                                                            5. Ну как минимум потому, что мемкеш хранит все данные в памяти (оперативная память быстрее жестких дисков). Но главное — мемкеш это хештаблица со скоростью доступа к данным не зависящим от кол-ва этих самых даных, т.е. O(1). Ни одна реляционная СУБД этим похвастаться не может. Так зачем я буду лишний раз тревожить СУБД по одному и тому же вопросу, если она мне один раз уже ответила.
                                                                                            6. Удобство — очень субъективный фактор.
                                                                                            • 0
                                                                                              Адово низкая производительность? Что для Вас адово низкая? Не замечал такого. Может просто не стоит увешивать таблицу, в которую много пишут огромным количеством индексов? Не знаю, может еще какие-то причины у вас были.

                                                                                              В два раза хуже чем PostgreSQL на операциях массовой записи.

                                                                                              Тоже работал с постгресом и не скажу, что танцев было меньше

                                                                                              Ну расскажите тогда про танцы. Я вот обычно смотрю количество памяти на сервере и настраиваю 4 параметрам в PostgreSQL и все. Дальше работаю с ним.

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

                                                                                              Зависит от того что делает эта логика. Если она активно лопатит данные в СУБД, лучше делать хранимкой. Будет работать намного быстрее.

                                                                                              База не должна быть нагружена логикой. В первую очередь это хранилище данных.

                                                                                              Логика в СУБД должна присутствовать, но в первую очередь она должна быть направлена на поддержание консистентности данных

                                                                                              По поводу долгих хранимок согласен. Но опять же, субд — не сервер для выполнения нереальных обработок, стоит как-то оптимизировать.

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

                                                                                              Ну как минимум потому, что мемкеш хранит все данные в памяти (оперативная память быстрее жестких дисков).

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

                                                                                              Удобство — очень субъективный фактор.

                                                                                              Я бы не сказал.
                                                                                              • –1
                                                                                                У меня такое ощущение, что вы начинаете грубить («страшная тайна», которую вы мне открыли). Поверьте у меня не мало опыта работы с различными СУБД, хоть и не со всеми и возможно меньше чем у вас. Я никогда не работал с оракл, но поработал с: постгресом, мускулем, монго, коуч, редис, беркли. Если вы выбрали такой тон, то:
                                                                                                1. Интересно посмотреть на тесты. Пока это голые слова. Вполне возможно, что так и есть, но подтверждений этому не вижу
                                                                                                2. С установкой мускуля танцев как таковых вообще нет. Конфиг под сервер и все. Я говорил про танцы, например при секционировании, при создании индексов, при синхронизации и репликациях.
                                                                                                3. Согласен и придерживаюсь такого же мнения. Но я говорил не про кол-во перебираемых строк, а про сложность самой логики. Она должна быть простой: перебрать все строки в таблице и найти минимум (понимаю, что это делается MIN, но более сложный и адекватный пример лень придумывать))
                                                                                                4. Опять же согласен
                                                                                                5. Ну при желании можно и и не так извратиться, но тут все таки скорее размазывание кода. То что это не мешает вам жить — временное явление, например, пока не наступит этап рефакторинга или изменения старого функционала.
                                                                                                6. Рассказываю страшную тайну вам: на высоконагруженных проекта редко используют один сервер подо все. Мемкеш, статика с нджинксом, динамика и мускуль — все на разных серверах. Мало того этих серверов несколько. Для мемкеша используется консистентный хеш и построен кластер, мускуль юзает шардинг.
                                                                                                7. Ну раз не субъективный, то мне удобно работать с мускулем. Если исходить из объективности моего мнения, то значит и вам это также должно быть удобно )
                                                                                                • 0
                                                                                                  1. Интересно посмотреть на тесты. Пока это голые слова. Вполне возможно, что так и есть, но подтверждений этому не вижу

                                                                                                  Такое тестирование в свое время проводил slonik-v-domene

                                                                                                  У себя я тестировал таким ПО как zabbix. Он довольно активно работает с СУБД. У него как раз профиль нагрузки перекошен на запись обновление и удаление. Простой пример. Когда zabbix начинал чистить старые данные, то в случае MySQL все операции записи вставали колом. В случае PostgreSQL на той же машине все работало.

                                                                                                  2. С установкой мускуля танцев как таковых вообще нет. Конфиг под сервер и все. Я говорил про танцы, например при секционировании, при создании индексов, при синхронизации и репликациях.

                                                                                                  Вообще речь идет про настройку MySQL под конкретную машину и там ручек на порядок больше чем в PostgreSQL. Причем частенько их еще крутить надо не тривиальным образом.

                                                                                                  Рассказываю страшную тайну вам: на высоконагруженных проекта редко используют один сервер подо все. Мемкеш, статика с нджинксом, динамика и мускуль — все на разных серверах.

                                                                                                  Я в курсе. Просто сейчас для MySQL есть замечательный плагин который позволяет его использовать как NoSQL. В результате memcached можно вообще не ставить.

                                                                                                  мускуль юзает шардинг.

                                                                                                  Это кстати частая причина почему его используют. Плюс типичный конфиг MySQL в таком случае это пишем на один читаем на другом.

                                                                                                  то мне удобно работать с мускулем.

                                                                                                  Вы как нибудь попробуйте написать аналитический запрос с вложенными запросами в MySQL ну так чтобы данных по декартовому произведению было хотя бы с миллион. Вот тогда будет не очень удобно работать с MySQL. У него отвратительный анализатор за счет этого приходится часто в работе смотреть explain и изменять запрос.

                                                                                                  • 0
                                                                                                    1. Ничего не могу ответить. Возможно так есть, но я с таким пока не сталкивался, хотя тоже использую заббикс
                                                                                                    2. Опять же не сталкивался с чем-то нетривиальным. Мне всегда хватало документации, чтобы настроить сервер под конкретную машину
                                                                                                    3. Не совсем понял как ваш ответ относится к цитируемой фразе.
                                                                                                    4. Ну так я кажется в самом начале спора сказал, что обе СУБД обладают и минусами, и плюсами. И плюсы мускуля перевешивают плюсы постгреса для текущего проекта
                                                                                                    5. Писал. Декартово произведение давало 20 млнов записей. И пришлось изобретать нетривиальный способ сделать такой запрос (кусками по сотне тысяч). А про анализатор… За всю жизнь долго втуплял в эксплейн всего один раз, когда по ошибке было создано 2 индекса, которые перекрывали друг друга, но один был менее эффективен. В том случае анализатор выбирал каким-то магическим образом то один, то другой индекс. Дело не в его ужасности, просто у него есть нюансы, которые достаточно быстро можно понять.
                                                                                                    • 0
                                                                                                      Ничего не могу ответить. Возможно так есть, но я с таким пока не сталкивался, хотя тоже использую заббикс

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

                                                                                                      Опять же не сталкивался с чем-то нетривиальным. Мне всегда хватало документации, чтобы настроить сервер под конкретную машину

                                                                                                      Почитайте www.mysqlperformanceblog.com/ узнаете много нового.

                                                                                                      3. Не совсем понял как ваш ответ относится к цитируемой фразе.

                                                                                                      Во многих случаях memcached можно будет и не использовать.

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

                                                                                                      И какие же там плюсы?

                                                                                                      5. Писал. Декартово произведение давало 20 млнов записей. И пришлось изобретать нетривиальный способ сделать такой запрос (кусками по сотне тысяч).

                                                                                                      И работало это явно весьма не быстро.

                                                                                                      А про анализатор… За всю жизнь долго втуплял в эксплейн всего один раз, когда по ошибке было создано 2 индекса, которые перекрывали друг друга, но один был менее эффективен. В том случае анализатор выбирал каким-то магическим образом то один, то другой индекс. Дело не в его ужасности, просто у него есть нюансы, которые достаточно быстро можно понять.

                                                                                                      А вы его почаще открываете и увидите как он работает. Он реально ужасен. Часто бывает достаточно переставить параметры местами.