Чат с разработчиками PostgreSQL

Все что в интервью - чистая правда. Сам частенько общаюсь с разработчиками PostgreSQL, благо они более доступны чем MySQL'ные (кто еще помнит, я рассказывал про возню с MySQL'ным багом, который фиксили целый год, при этом, они утверждали, что "суслика нету" :-).

MySQL'овцам надо быть нежнее... еще нежнее... :-)

Согласен. Я также заметил эту "закономерность" и с другими проектами под GNU лицензией - как правило разработчики более "озлоблены" и кидаются "use bugzilla" не гладя налево и направо. В то время как например с FreeBSD core members связаться гораздо проще и общаться с ними тоже приятнее - меньше пальцов гнут.

ИМХО

Может быть правильнее будет сказать "меньше пальцев GNUт"? :)

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

НЕИМХО

В данном случае, это не "чат", а "разговор" или "беседа".

Доступны как правило разработчики той системы которая менее популярна! Как только порог таких "общительных" пользователей переваливает за определенную критическую отметку - вне зависимости от лицензии, если это не платный суппорт то разработчики вас "посылают" далеко в багзиллу и "чатится" им тоже некогда :)

Я не хочу этим сказать, что PostgreSQL не достойный продукт, просто в opensource кругах он стал менее популярным, чем аналогичные разработки от мира GNU.

Dlja chata est' IRC, tam ochen' interesno poobshatsja. Ja tam ne videl Marc Fournier ili Josh Berkus, no rebjata kompetentnye, i ochen' starajutsja pomoch'. -- izvinite za translit

> Я не хочу этим сказать, что PostgreSQL не достойный продукт, просто в opensource кругах он стал менее популярным, чем аналогичные разработки от мира GNU.

А кто у нас стал более популярным? MySQL не предлагать - он ниразу не гнутый...

vrode nachinaetsja raskrutka SQLLite

sql lite - public domain, причем тут GNU ?

>>Я не хочу этим сказать, что PostgreSQL не достойный продукт, просто в opensource кругах он стал менее популярным, чем аналогичные разработки от мира GNU.

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

чем хороша упомянутая в "чате" Firebird?

проста, быстра, поддерживает развитую логику ... Мне нравится. Тока нет гетерогенности, архивных логов, репликации

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

>MySQL не предлагать - он ниразу не гнутый...

~/mysql-4.0.20$ head -n1 COPYING
GNU General Public License

>Я не хочу этим сказать, что PostgreSQL не достойный продукт, просто в
>opensource кругах он стал менее популярным, чем аналогичные разработки
>от мира GNU.

Извините, "Фабрика звезд" - тоже популярна, однако это не значит, что Вагнер и Бах - отстой. Скорее наоборот :) Популярность - не тот критерий.

MySQL - детский сад по сравнению с возможностями PostgreSQL.

Это точно !

Хе.. Возникает тема 'Postgres', начинают говорить про MySQL. Возникает тема с MySQL, начинают обсуждать Postgres. Прям как Ленин и партия - близнецы братья.

Их надо скрестить! PostMySQL получится.

> MySQL - детский сад по сравнению с возможностями PostgreSQL.

"Детский сад" позволяет легко вытащить мата-данные к таблице - имена полей, длину, флаги (primary_key, not_null). А когда можно будет получать не через задний проход то же самое во "взрослой" БД Postgresql? Мне нужно автоматом генерить функции для работы с базой, и я должен точно знать все атрибуты каждого поля.

> Доступны как правило разработчики той системы которая менее популярна!

Видимо, samba не пользуется популярностью ? :)

На первый мой вопрос самбист ответил минут через семь. Вобщем, в течении часа я выяснил, что кроме как всунуть в самбу pdb-модуль, альтернативную авторизацию не прикрутишь. А плагинный интерфейс в этой области (и если память не изменяет, во многих других областях) можно ожидать ближе к версии 4.0. Судя по всему, самбу вообще никто не использует :)

> "Детский сад" позволяет легко вытащить мата-данные к таблице - имена полей, длину, флаги (primary_key, not_null). А когда можно будет получать не через задний проход то же самое во "взрослой" БД Postgresql?

Гм... Насколько я помню, перловые DBD+DBI это умеют. Следовательно, информацию получить можно. Обычно через RTFM. В крайнем случае, если совсем уж лениво читать, обычными селектами через таблицы pg_*. Ну или посмотреть, как это делает клиент pgsql, если легче понять чужой код, чем написать свой. По крайней мере, я получал список таблиц по определенному критерию и названия полей в них (мне только эта информация нужна была).

А вообще это можно было делать еще в незапамятные времена :)

GNU != [L]GPL
а на MySQL, с их новой жлобской политикой, я бы ставить не стал

SELECT * FROM information_schema.tables;
SELECT * FROM information_schema.columns;

> "Детский сад" позволяет легко вытащить мата-данные к таблице

Что толку от "метаданных", если нет поддержки view? :-)

http://dev.mysql.com/doc/mysql/en/views.html

и что нам проект коорый давно и успешно работает перетаскивать на мускуль в котором только недавно появились нужные фичи? кстати а когда их доточат и оттестят? а аналог PL\pgsql PL\perl в мускуле есть?

Да не нужно это все в мускуле. Не для того он точен. Виды, триггера.. Все это излишества если надо писать бд на 5-10 табличек слабо завязанных друг на друга. Если его функциональность поднимут до постгри, вряд ли останется его шустрота.. А для тех, кому и постгри мало, есть монстры потяжелее.

ЗЫ К каждой стенке надо подбирать свой гвоздик.

> SELECT * FROM information_schema.columns;

А ты сам видел, что этот запрос выводит? Такое ощущение, что сделано для галочки... character_maximum_length - везде NULL. Информации о primary key вообще нет. Ну очень "полезная" информация. Ф топку.

> Что толку от "метаданных", если нет поддержки view? :-)

Рассказываю ещё раз для тех, кто не слышал. Мета-информация нужна для автоматической генерации интерфейсов и моделей работы с БД. Написан универсальный класс. Ему нужно знать только имя таблицы. Он на лету генерит готовый CRUD (create-update-delete) интерфейс для работы с таблицей и с её связями. Что-то похожее в очень простом виде сделано в ruby-on-rails.

> Гм... Насколько я помню, перловые DBD+DBI это умеют.

Перл не воспринимаю как язык, но даже его DBD+DBI качественно вытянуть нужную информацию увы, не могут. Где длины полей? Они нужны как воздух. У постгреса любое поле типа varchar выдаёт (-1) в качестве длины поля. Почему на детской БД mysql таких проблем не было с рождения?

> http://dev.mysql.com/doc/mysql/en/views.html

Это ты про 5.0, который в тотальном девелопменте??? Не-е-ет, нам такого счастья нафиг-нафиг... :-)

Работать надо сейчас, и желательно чтобы в последней трети выполнения задания не выяснилось, что где-то есть баг, который не дает сделать представление на основе двух других представлений, каждое из которых собрано еще из трех (это не "наворот", а вполне может понадобиться).

P.S.: я люблю MySQL. Для простеньких берущихся "в лоб" задачек (всети логи, базы из пяти-десяти табличек, форумы и т.д.) он, как говорится, "самое то" - но когда затевается что-нибудь более-менее тяжелое, его возможностей катастрофически не хватает.

> Рассказываю ещё раз для тех, кто не слышал.

Да знаю я что такое метаданные. Сам использовал, и не раз.

А насчет "недоступности" их из Postgres ты погорячился - даже в php-шном интерфейсе к postgres'у есть возможность "выдрать" эти данные, JDBC-драйвер тоже умеет это делать. Cоответственно, в штатном клиентском интерфейсе это предусмотрено, и если твоя тулза не умеет этого доставть... Это только твои и ее (тулзы) проблемы.

> character_maximum_length - везде NULL.

abs=# SELECT DISTINCT character_maximum_length FROM information_schema.columns ;
 character_maximum_length
--------------------------
                        8
                       13
                       15
                       16
                       18
                       20
                       30
                       32
                       36
                       40
                       48
                       64
                      128
                      168
                      255
                     1024

(записей: 17)

> Информации о primary key вообще нет. 
information_schema.table_constraints

>Ф топку.
нет в детский сад

>Это ты про 5.0, который в тотальном девелопменте??? Не-е-ет, нам >такого счастья нафиг-нафиг... :-)

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

> имя таблицы. Он на лету генерит готовый CRUD (create-update-delete) интерфейс для работы с таблицей и с её связями.

а зачем нагружать базу постоянными дополнительными запросами метаинформации ? не проще однин раз код (с/пере)генерять ?

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

и что это даст кроме проблем ?
- по фичам все равно еще не сравниш
- ACID скорость под вопросом (не видел пока адекватных тестов)
- про стабильность пока лучше помолчать
- нужно купить коммерческую лицензию (или раздовать свои проекты под GPL)

> даже в php-шном интерфейсе к postgres'у есть возможность "выдрать" эти данные

Да, я знаю, что можно. Напоминает вырезание гланд через задний проход. И всё равно не решается пролема с длинами полей varchar!

> SELECT DISTINCT character_maximum_length

А здесь другая засада. Показывает _только_ длину varchar полей ;) Остальные поля - NULL.

Ну дык сколько же запросов надо сделать чтоб получить полную картину о полях и их атрибутах, которую легко отдаёт mysql?

> а зачем нагружать базу постоянными дополнительными запросами метаинформации ? не проще однин раз код (с/пере)генерять ?

Не проще. Имена таблиц - переменные. А для mysql затраты на получение мета-данных совсем ничтожные. И потом, чтобы сгенерить всё равно нужно иметь эти мета-данные!

> А здесь другая засада. Показывает _только_ длину varchar полей ;) Остальные поля - NULL.
а у остальных полей длина представляет интерес ?

>А для mysql затраты на получение мета-данных совсем ничтожные.
а по сравнению с затратами на основные запросы CRUD ?)

к тому же, не думаю что для большенства БД скорость работы с мета-данными является приоритетом

для работающих, а не балующихся, работа с необходимыми вещами (PL\pgsql) важнее рюшечек (инфа о таблице). ты сначала вообще говорил что инфу нельзя вытянуть. потом когда показали, начал придираться, т.е. в постгри ты вообще плаваешь. так какого лешего ты лезешь со своими детскими проблемами к людям которые и мускуль и постгри в своей работе используют. для даунов разъясняю - и с п о л ь з у ю т п о н а з н а ч е н и ю

> (PL\pgsql) важнее рюшечек (инфа о таблице).

Для меня PL\pgsql - это рюшечки. А мета-инфа о таблицах - важнейшая базовая информация.

> т.е. в постгри ты вообще плаваешь.

А что, ты видел здесь хоть кого-нибудь кто летает? Правильный ответ так никто и не дал.

> а у остальных полей длина представляет интерес ?

При формировании полей воода интерес представляют длины всех полей.

> а по сравнению с затратами на основные запросы CRUD ?)

Да. А в чём смысл смайлика?

> не думаю что для большенства БД скорость работы с мета-данными является приоритетом

БД тут вообще никто не спрашивает, что у неё там в приоритетах. Есть приложение, которому мета-инфа нужна, и нужна постоянно. Я так понимаю, что разработчики "взрослой" БД никогда не озадачивались вопросом о том, что на основе их базы кто-то будет автоматически генерить интерфейсы. Очень печально.

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

Испытывать SQL на своем проекте? Может наоборот?

> При формировании полей воода интерес представляют длины всех полей.
мы говорили в контексте возможности, а не в контексте реализации.

>Да. А в чём смысл смайлика?
ну хотя бы в том что любой запрос проходит несколько обязательных стадий обработки и гоняется между клиентом и базой, и это сказывается на времени отклика под нагрузкой.

> Я так понимаю, что разработчики "взрослой" БД никогда не озадачивались вопросом о том, что на основе их базы кто-то будет автоматически генерить интерфейсы. Очень печально.

Разработчики взрослой БД реализовали INFORMATION_SCHEMA - полный и стандартный способ доступа к мета-информации, а пока не вышла пятерка, противопоставлять ему DESCRIBE и SHOW глупо.

У меня есть свой CRUD (хотя на самом деле это намного больше чем просто CRUD), дак вот при разработке у меня даже мысли не было постоянно лазить в базу за мета-данными. И не потому что это вызывало проблемы, а просто для приличного пользовательского интерфейса sql мета-данные слишком "бедны", все равно нужно дополнительно описывать подчиненность, описания, правила сортировки, валидаторы, .... Поэтому все равно требуется более "содержательный" источник мета-данных, который можно синхронизировать с мета-данными БД при их изменении.
А по большому счету основой таких штук должна быть MDA, а не на реляционная модель, плохо что в свое время я это не осозновал.

То о чем ты говориш - это проблемы дизайна твоего приложения завязанного на нестандартную фичу и неоптимальную производительность.

>А здесь другая засада. Показывает _только_ длину varchar полей ;) Остальные поля - NULL.

Я в шоке! Ну и индивидумы здесь попадаются! Милай, character_maximum_length показывает именно то, о чем говорит его название. NULL - у полей с типом text, в виду безразмерности и у не символьных полей. Нахуй иди!

> Милай, character_maximum_length показывает именно то, о чем говорит его название.

Дарагая, напоминаю твоим куриным мозгам исходную задачу: вытянуть с
наименьшими затратами буквально следующие данные:

имя_таблицы | имя_поля | тип_поля | размер_поля | флаг_primary_key

Всё! Наваяй запросик для постгреса, а? И чтоб не на три экрана ;)
Не можешь? Дык иди в 3.14зду!

> дак вот при разработке у меня даже мысли не было постоянно лазить в базу за мета-данными.

Ну и немного, значит, у тебя мыслей. Да, часто приходится описывать дополнительные параметры помимо мета-информации. НО! Не менеее часто приходится работать с простейшими справочными таблицами из двух полей: key/value. В моём случае CRUD разрабатывался для целей администрирования торговой программы, в которой подобных справочников было под сотню.

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