Десять главных недостатков PostgreSQL
Проработав ежедневно три месяца на PostgreSQL я бы хотел подытожить - штука это вполне работоспособная, с успехом конкурирующая с MS SQL, однако удержаться от нескольких критических замечаний совершенно невозможно.
В какой-то мере эта страничка - это пожелания и претензии команде PostgreSQL team, которая должна понять, что не все благополучно в королевстве PostgreSQL.
1. Инсталляция
Это главный недостаток PostgreSQL - отпугивающий 99% пользователей от использования PostgreSQL. У PostgreSQL нет сертифицированного дистрибутива ни для Linux ни для Windows. В основном дистрибуцией занимается http://www.enterprisedb.com/ - именно на нее происходит редирект при нажатии download на http://www.postgresql.org/. Второй важный источник дистрибутивов - репозитарии OpenSuse, Ubuntu и других дистрибьюторов Linux.
За три месяца плотного погружения в PostgreSQL я примерно два десятка раз устанавливал PostgreSQL и 17 раз - это были адские шаманские танцы с бубном, продолжающиеся часов по 10. В трех случаях установилось за 10 секунд - 32-х разрядный дистрибутив для Linux на OpenSuse 11.2 - взятый с EnterpriseDB, 32-з разрядный дистрибутив OpenSuse 11.1, взятый из репозитария OpenSuse и 32-х разрядный дистрибутив, установленный на русифицированную крекнутую XP.
Основная проблема инсталяции - это то, что идеологи PostgreSQL приняли на себя обязательства расписать права на директорию с каталогом базы и запустить сервис PostgreSQL именно под ограниченным логином. В результате этого неверного подхода защищенная директория после инсталяции оказывается пустой, причем даже при установке на Linux.
Здесь идеологи PostgreSQL сами себя загнали в ловушку. Приняли на себя обязательство, которое не нужно было на себя принимать. Они решили своим инсталятором создавать учетные записи в различных операционных системах и расписывать права по каталогам PostgreSQL разных учетных записей операционной системы. Результат вполне предсказуемый - особенно если осознать что на все виндаусы от Windows 95-ME-XP-Vista-7 до NT-2000-2003-2008 они сделали один-единственный дистрибутив. Соответственно, вариантов падения инсталлятора ровно столько - сколько вариантов запуска: под терминальным сервером, под ограниченным логином, под админским логином, с расшаренных ресурсов, под такой виндузней, под сякой.
И автоматически эта идеологическая ошибка приводит к отсутствию сертифицированного дистрибутива PostgreSQL. Кто, например, может гарантировать корректную работу этого дистрибутива например на Windows 7 - если билогейтсовцы меняют правила игры каждую неделю с каждым новым патчем.
Отказавшись от этой изначально неверной посылки - точного сопряжения с закрытым и меняющимся кодом, являющимся собственностью Билла Гейтса (сделав инсталяцию minimum security) - можно было раз в 10 или в 100 увеличить количество пользователей этой неплохой СУБД. Оставив решение проблем безопасности доступа к этому каталогу на усмотрение администратора виндузни.
Хотя сравнивать качество инсталяции PostgreSQL с MS SQL невозможно вообще - MS SQL ведь вообще никак невозможно установить на Linux - даже после 1000 часов шаманских танцев с бубном над кампутером. А ведь мы еще помним как микрософтовская же студия даже на специально предназначенный для установки Evaluation Windows не устанавливалась.
Если у вас PostgreSQL не ставится ни в какую - возьмите тупо загрузочную флешку с PostgreSQL, например эту - не последняя версия, но работает. Поищите в инете поновее или вообще попробуйте сделать флешку с PostgreSQL сами. Как делаются такие флешки - я описал тут Загрузочные компакты и флешки (bootable LiveCD and bootable USB)
2. Отсутствие примеров кода и литературы на русском
Людям, привыкшим к MSDN (при всех его недостатках) диковато смотреть на документацию, где сложная синтаксическая конструкция или функция просто обьявляется как факт ее существования - никак не поясняя это практическим примером. И это вторая проблема этой мощной СУБД.
В интернете все в основном пережевывают документацию - конкретно сайтов с примерами каждой конструкции и функции нет. Конечно на специализированных форумах есть гуру, которые знают все - и они обычно доброжелательно отвечают, но лично я бы предпочел для начала хороший глобальный ресурс с примерами - а уж потом обращение за помощью к гуру.
К сожалению, приходится констатировать и полное отсутствие печатной литературы на русском. Была на русском какая-то книжонка пятилетней давности, которую размели за неделю - с тех пор вообще ничего. Как будто этой СУБД не существует вообще.
А ведь это сложная СУБД и сложный язык, например встроенных функций (кроме содержащихся в CONTRIB) она содержит более двух тысяч - причем это такие функции и операции - о которых никто программирующий на MS SQL никогда не слышал. Для понимания этого огромного массива информации нужны примеры, литература на русском. Но видимо билогейтсовцы как-то решают вопросы в крупнейших российских издательствах, чтобы тысячи и тысячи новых издаваемых книг бесконечно пережевывали только их технологии.
Заметьте, что на английском только в 2009-м вышел году огромный пятитомник с описанием языка PostgreSQL и в каждом томе 300-500 страниц. Плюс только в 2009-году вышел учебник по администрированию PostgreSQL, PostgreSQL для разработчика СУБД, PostgreSQL и Windows - не говоря уже о более ранних книгах.
3. Неверная работа окружения PostgreSQL
Окружение PostgreSQL может работать неверно, в частности pcbouncer, в настройках по умолчанию зверски перемешивает пул записей. Те первый инсерт выдается из проги раньше второго, а доходит до базы первый позже второго. Преодолевается эта проблема настройков пула коннектов, которой никто обычно не занимается в MS SQL - но в PostgreSQL этой темы избежать не получится (так же как например не получится избежать понимания в MS SQL что такое Surface Area).
MS избегает проблем своих дополнительных компонентов проще - не только полностью исключая Analysis, Reporting, SSIS и другое окружение сервера из бесплатной поставки, но и кастрируя до нуля функционал собственно SQL Express в бесплатной комплектации. SQL Express - это еще то чудо: без аудита, без репликации, без компрессии, без материализованных вьюшек, без секционирования, с однопоточным обращением к индексам, без полнотекстового поиска, без мастеров экспорта/импорта данных, без оптимизатора JOIN-соединений, без почтовых уведомлений, без виртуализации, без сборок, без тьюнинг-адвизора, без профайлера... А некоторые дополнительные компоненты MS SQL вообще никогда не работали - это просто плод воображения менеджеров MS.
Напротив PosgreSQL даже в самой минимальной бесплатной инсталяции полностью укомплектован не только менедером коннектов, агентом, репликацией, секционированием, но и любой из четырехсот дополнительных компонентов может быть в любой момент без ограничений добавлен в установку по умолчанию.
4. Катастрофические падения сервера PostgreSQL
Сервис сервера иногда завершается катастрофической ошибкой. У меня это бывает при совершенно обычных операциях - гоняешь свой прикладной софт в отладчике - хопа, а в какой-то момент сервер PosgreSQL умер. Перегружаешь машину - PostgreSQL оживает. Хотя иногда и не оживает, удивляя своими сообщениями.
Справедливости ради заметим что дорогой платный софт бывает несравненно более худшим. По моим наблюдениям PostgreSQL поднимается самостоятельно после перезагрузки все же чаще, чем например микрософтовский агент.
А когда я начинал работать на Visual Studio 2005 (а она на тот момент стоила пять тысяч долларов) - она падала у меня не менее двадцати раз на дню (каждые 15 минут по-новому) - имея на момент выпуска 1800 задокументированных багов (сейчас задокументировано десять тысяч багов). А ведь это же копеечная прога, не сложнее той же IDE Eclipse, полностью бесплатной кстати. И это безобразие продолжалось не менее года, пока не вышел сервис-пак - 700 мегабайт кода с исправлениями ошибок купленной за пять тысяч долларов Visual Studio 2005.
5. Отсутствие реакции программистов PostgreSqL на задокументированные баги PostgreSQL
Вот например этот баг PostgreSQL с правами на каталог с директорией DATA был задокументирован множеством пользователей девять месяцев назад. Единственная реакция проггеров PostgreSQL на этот баг - вялое обсуждение, какой же ключ в правилах наследования прав на каталог data надо поставить. И больше ничего за 9 месяцев не произошло. Как прога падала - так и падает все эти девять месяцев.
Впрочем, как мы знаем, когда программисты работают даже за 300 тысяч долларов в год у Билла Гейтса - они спешат исправлять свои баги не быстрее программистов PostgreSQL, а еще медленнее. И в основном билогейтсовские чудо-программисты прославились выпуском продуктов типо Notification Server для SQL 2005 - которые не заработали вообще ни у одного человека в мире. Вот так работать можно - никто прогу запустить не смог - и баги вообще можно не исправлять!
6. Отсутствие полной поддержки самых массовых языков программирования VB и С#
PostgreSQL имеет встроенную поддержку многих языков программирования C, C++, PL/Java, PL/R, PL/Lua, PL/LOLCODE, PL/Perl, pl/PHP, PL/Python, PL/Ruby, PL/sh, PL/Tc, PL/Scheme. Но нет полной поддержки двух самых важных языков для людей, мигрирующих с билогейтсовской платформы в свободный мир Linux - VB и С#.
Хотя VB родился (более двадцати лет назад) в недрах империи зла (и лет восемь назад там же родился C#) - к настоящему времени оба эти языка уже имеют полноценную поддержу на платформе LINUX в рамках MONO. Полноценную - но не в PostgreSQL.
Из VB и C# можно лишь обратиться к процедуре PostgreSQL, но сделать на MONO полноценную сборку, которую можно откомпилировать и утопить во внутрь сервера PostgreSQL, а потом сделать вокруг нее обвязку уровня SQL - это невозможно. Например я бы с удовольствием утопил вот этот свой код во внутрь PosgreSQL (что я делаю постоянно c MS SQL). Увы, настолько полную поддержку VB и C# имеют только в MS SQL.
Тем не менее, пока вы не столкнулись с этим функциональным ограничением - работать с PostgreSQL на NET/MONO через NPGSQL можно очень даже неплохо.
7. Потеря форматирования программного кода
Людям воспитанным на культуре MS SQL диковато, что программный тест вьюшек перемешивается после записи вьюшки в базу. Подобная мерзость постоянно происходит в коде MS Visual Studio - создал ASPX-код, открыл-закрыл файл - и вместо своего кода видишь кучу перемешанных помоев, на которые можно полдня смотреть, но так и не свой узнать собственный код. Да что там ASPX-код! - микрософтовцы за 8 лет существования своей студии даже текст Javascript подсвечивать нормально не научились.
К этой мерзости микрософтовской Visual Studio (за 12 тысяч долларов в полной комплектации) мы все уже привыкли, но микрософтовкий SQL-сервер работает в этом плане безукоризненно (сохраняя форматирование и другие параметры в виде дополнительных свойств вьюшки). В отличии от PostgreSQL, который этого не умеет.
Впрочем потеря форматирования замечена в PostgreSQL только во вьюшках и параметрах функций - а билогейсовская студия теряет ВСЕ форматирование программного ASPX-кода, и даже вообще неспособна правильно подсветить вводимый код программы - что не помешало Биллу Гейтсу заработать миллиарды долларов на продажах своей студии.
8. Изменение локализации
Для людей с MS SQL опытом работы в PostgreSQL могут возникать странные проблемы в неожиданном месте. В MS SQL все привыкли менять кодировки базы одним кликом мышкой. А в PostgreSQL для изменения локализации надо минимум поднять реплликацию (!) на сервер с другой локализацией.
Возможно, это нельзя отнести в полной мере к недостаткам, возможно это можно считать особенностью PostgreSQL. Так же точно для людей с опытом работы в PostgreSQL будет удивительным открытием такое осложнение, что в MS SQL существует две базы логинов - Windows база логинов и собственная база логинов MS SQL-сервера. И то, что конкретной базой владеет совсем и не те и не другие, а третья сущность - владельцы схемы. И надо учится правильно работать с двумя базами логинов и с сопоставлением контекстов этих логинов контексту схемы. Причем диалоговые окна сопоставления этих контекстов устроены в MS SQL совершенно неочевидно.
Синтаксис у PostgreSQL менее крученый, чем в MS SQL. Например в MS SQL все привычно закручивают семиэтажные конструкции даже в Delete. В PostgeSQL таких сложных конструкций нет - переход с крученого синтаксиса TSQL на упрощенный ANSI-синтаксис PostgreSQL происходит для MS SQL программистов совершенно незаметно и безболезненно. А вот PostgreSQL школа программистов, думаю, немало удивится TSQL.
Думаю, SQL-программисты с PostgreSQL школой удивятся и многим другим осложнениям MS SQL, например понятию именованной инстанции сервера. Со всеми, с кем я разговаривал об этом - они мне так и не поверили, что несколько именованных инстанций сервера и даже разных версий (например SQL2000, SQLExpress, SQL2005, SQL2008) - могут уживаться на одном кампутере на том же самом порту.
Да и все прочие ограничения и осложнения MS SQL, думаю, немало травмируют мозг PostgreSQL-программистов. Одно то, что в MS SQL нельзя результатом формируемым одной процедурой - воспользоваться в другой (или во вьюхе) - одно это чего стоит! Зато со сменой локализации в MS SQL нет никаких проблем - один клик и готово. А в PostgreSQL это оказывается немалая проблема.
9. Отсутствие Intellisense при программировании
Хотя функционально и по скорости PostgreSQL во многом превосходит даже самый дорогой и полнокомплектный MS SQL (например можно вернуть агрегат/массив из нескольких столбцов в виде одного столбца, сделать перегрузку функций, унаследовать одну таблицу от другой и так далее) - но технически базовые средства работы программиста PostgreSQL не доведены до совершенства.
Несмотря на многие явные достоинства PostgreSQL - в основных бесплатных клиентах для работы с PostgreSQL отсутствует контекстная подсказка при SQL-программировании. К этому сервису все привыкли не только в MS SQL - даже в самых скромных СУБД сегодня работают только так. А в инструментах работы с Postgres имеется множество раздражающих мелочей. Например в MS SQL просто кликаешь на сообщение об ошибке - и курсор позиционируется на неверном символе, вызвавшем ошибку. А в PostgreSQL попробуй еще найди строку с ошибкой. Это не является недостаком ядра PostgreSQL - это недостаток бесплатных широкораспростаненных клиентов для программирования в PostgreSQL - которые выглядят великолепно лишь по сравнению с убогостью текстовой FreeBSD или командной строки plpqsql, но совершенно не соответствуют современным требованиям к интегрированным средам SQL-разработки.
Справедливости ради заметим, что Intellisense хотя и работает в MS SQL, но работает неудовлетворительно. В частности загрузка SQL-структуры для подсказки делается крайне редко. Те ты добавляешь например при разработке новый столбец, но в подсказке он не появляется, пока не перезакроешь MS SMS. Такая техника хороша для админов, которые работают с годами не меняющейся базой, но совершенно неприемлима для активного SQL-девелопмента.
Кроме того, микрософтоский клиент MS SMS к MS SQL серверу, хоть и работает с Intellisense, хоть и показывает строку с ошибкой по клику на ошибке - но на моем лично кампутере является наиболее часто зависающей программой. Это конечно не Microsoft Visual Studio 2005 с десятью тысячами багов под тридцатью кнопками, но зависания MS SMS у меня происходят не реже раза в два месяца. Обычно когда резко тыкаешь какую-то последовательность русских букв. Я подозреваю, что причина этому как раз Intellisense - ибо он дергается, но раскрытся не успевает и кампутер подвисает полностью. По факту получается, что при работе в MS SMS кнопку RESET надо держать в поле зрения постоянно.
10. Сервис SQL-программиста
В PostgreSQL есть много особенностей, которые можно отнести как к недостаткам, так и к особенностям PostgreSQL. Например в MS SQL всегда можно в любой момент заменить в таблице тип поля, тип возвращаемой процедурой данных, тип принимаемого параметра. При этом не требуется делать огромную пирамиду Drop Cascade всех объектов, зависимых от изменяемого обьекта.
В PostgreSQL модификации обьекта, от которого что-то зависит - сделать нельзя вообще. Изменения таблиц, типов возвращаемых параметров функций возможно только после предварительного удаления всей пирамиды обьектов, зависимых от изменяемого объекта. С последующей загрузкой всей пирамиды обьектов заново.
Справедливости ради, заметим, что в MS SQL - это основной источник трудноуловимых ошибок. Он хоть и позволяет выполнить указанную операцию, но вьюшки (зависящие от измененной таблы) после модицикации показывают полную ерунду и требуют ручной перекомпиляции - но не всегда. Если поле добавляется в конец таблы - перекомпиляция зависимых от изменяемой таблы вьюх не требуется. С другой стороны, в PostgreSQL вообще нет такой операции как изменение порядка столбцов или вставка столбца в средину списка.
С точки зрения SQL-программиста, занимающегося активным девелопментом и несколько раз в день меняющего SQL-структуру СУБД с самого низа - меня лично в равной степени не удовлетворяет ни работа MS SQL, ни работа PostgreSQL. В PostgreSQL важнейшие для разработчика операции без лишнего гимороя сделать нельзя вообще, а в MS SQL всегда просто внести любую модификацию - но с возможными в последующем глюками. Что лучше?
SQL-программисты с PostgreSQL школой будут поражены, узнав что в MS SMS нельзя даже выгрузить таблицы с данными в виде текста с командами INSERT. MS SMS даже не запоминает историю всех операций программиста с СУБД. Для этого надо запускать профайлер, настраивать в нем шаблоны, коннектить его с серверу, решать все вопросы с безопасностью - да и вообще профайлр входит лишь в некоторые самые дорогие версии MS SQL. A pgAdmin автоматически и всегда точно ведет полный журнал всех выполняемых программистом операций. Не говоря уже о такой элементарной операции, как разгрузка табличных данных в виде последовательности команд INSERT.
Микрософтовский клиент для работы с MS SQL Server до такой степени убогий, что мои нервы однажды не выдержали работы в нем и я написал собственный инструмент для работы с MS SQL Server. Вы можете сгрузить его отсюда - ScriptManager. Жаль что pgAdmin написан не на бейсике - а то бы я потратил пару вечеров и добавил бы в него нужный функционал.
)
|
|