[Comm] Re: MySQL & Postgresql

[Денис Смирнов]

On Tue, Apr 13, 2004 at 02:56:17PM +0600, Alexander Leschinsky wrote:

 AL> Сударь лезет в бутылку??? Ладно, это _Ваш_ выбор. Ответ у меня простой
 AL> А ткперь разберем Ваш оригинальный ответ...

Сударь не умеет отматывать треды, или я окончательно свихнулся? Вроде бы
то было моё единственное письмо в этом треде.
 
 AL> Чем же вреден Ваш совет, ктоме того, что он вообще "не в тему".
 AL> 1. Статистика по репрезентативной выборке утверждает, что LDAP является
 AL> "в среднем по больнице" значительно более редким установленным и
 AL> работающим сервисом, чем какая-никакая RDBMS, которые входят де-факто в
 AL> состав "must have" служб, функционирующих практически у любого,
 AL> связанного с сетевыми услугами (я могу предмтавить ситуацию, где RDBMS
 AL> не используется, а все работает, но это - пограничные случаи, исключения
 AL> из правил)
 AL> 2. В связи с пунктом 1 уместно вспонить о бритовке Оккама, и не заводить
 AL> еще одну дополнительную сущность, потому что, кромк всего прочего
 AL> "Простейшие не болеют" и "Чем тоньше - тем управляемее"

OpenLDAP внутри явно проще, чем PostgreSQL :) Но второй при этом
управляемее (триггеры рулят).
 
 AL> 3. MySQL работает как правило _быстрее_ на выполнение аналогичных
 AL> запросов, чем LDAP, что в некоторых ситуациях может также быть
 AL> определяющим

Фишка в том, что далеко не все frontend'ы умеют держать пул установленых
соединений с SQL-сервером. В случае LDAP накладные расходы на установление
соединения меньше (AFAIR). Это и является определяющим фактором.
 
 AL> 4. Использование LDAP-транспорта в MTA началось позднее, чем SQL,
 AL> следовательно - потенциально граблей необнаруженных в кустах разбросано
 AL> больше

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

Пожалуйста, будьте осторожнее с применяемой логикой, дабы она была более
логичной :)
 
 AL> 5. Администрирование и сопровождение LDAP является (опять же
 AL> "усредненно") более нетривиальной задачей, чем аналогичные функции в
 AL> случае RDBMS (элементарные в случае My, более сложные... но в
 AL> пределах... в случае PostgreSQL). И задача адаптации backend'а в случае
 AL> изменения "правил игры" може стать неподъемной задачей. Сколько
 AL> подписчиков _этого_ листа имеют собственные MTA и сколько из них при
 AL> необходимости могут подхатчить схему, если Гугль им ответа не даст???

А вот это действительно ключевой параметр. И именно по нему в бою у меня
сейчас машина на PostgreSQL. А PostgreSQL там именно потому, что поднимать
её надо было быстро, а с MySQL я тогда был не знаком вообще -- 2 дня на
разбирательство тогда мне были критичны.

 AL> Так что советую - думать (головой), прежде чем ляпнуть чушь, и уметь
 AL> признать неправоту, если запалился. Errare humanum est, а рогом в землю
 AL> упираются ЛАМЕРЫ

Спорить с этим не буду, ибо правильно.
 
-- 
С уважением, Денис

http://freesource.info