(no subject)

[kastaneda]

Уважаемые коллеги, расскажите мне как-нибудь на досуге, за что вы любите PostgreSQL. Чем больше узнаю про эту СУБД, тем больше хочется плеваться ядом. Я не сомневаюсь, что эту систему разрабатывали умные люди; зато я подозреваю, что эта система не предназначена для использования живыми людьми в реальном мире.

Контрольные вопросы:

• почему хранилище данных привязано к версии СУБД?
• зачем мне беспокоиться про vacuum?
• что за чертовщина с кодировками и collate?
• сколько времени надо на переход с версии 7.x на 8.x?
• имеет ли значение производительность системы?
• им слабó реализовать LIMIT #,# или они хотят «построить» всех остальных?
• кто, чёрт побери, придумал такую систему аутентификации?

Может быть, когда-то я изменю свою точку зрения, но здесь и сейчас PostgreSQL мне категорически не нравится.

Comments

[the-petrovich.livejournal.com]

- почему хранилище данных привязано к версии СУБД?
А почему вас это волнует? У програмиста есть SQL интерфейс, а то как где и как оно хранится - не ваша проблема

- зачем мне беспокоиться про vacuum?
Действительно? А зачем ты беспокоишся? Поставь pg_autovacuum

что за чертовщина с кодировками и collate?
А где её нету? Юзайте UTF8 и будет вам щастье. Правда без collate все-равно никак.

сколько времени надо на переход с версии 7.x на 8.x?
Да не много. Чтение доков, дамп, установка 8.x, рестор.

имеет ли значение производительность системы?
Конечно.

им слабó реализовать LIMIT #,# или они хотят «построить» всех остальных?
А чем LIMIT # OFFSET # не понравился?

кто, чёрт побери, придумал такую систему аутентификации?
Кстати, очень удобная и гибкая.

[mambaram.livejournal.com]

А мне не нравится мускуль. И таки шо?

[blinohod.livejournal.com]

> почему хранилище данных привязано к версии СУБД?

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

> зачем мне беспокоиться про vacuum?

Смотри от вет the_petrovich про autovacuum.
У меня оно по дефолту оказалось включенным.

> что за чертовщина с кодировками и collate?

+1, если надо их несколько вариантов иметь. Впрочем, я как-то находил пакет, который collation с поддержкой NLS делал через C stored procedures.

> сколько времени надо на переход с версии 7.x на 8.x?

Если экзотикой не пользоваться - время на dump/restore.

> имеет ли значение производительность системы?

Смотря для чего :)

> им слабó реализовать LIMIT #,# или они хотят «построить» всех остальных?

Смотри мой ответ здесь. Или покажи мне LIMIT #,# в Oracle и DB2.

> кто, чёрт побери, придумал такую систему аутентификации?

А чем она тебе не нравится?
Как по мне, то вполне удобно и понятно.

[zmeuka.livejournal.com]

> почему хранилище данных привязано к версии СУБД?

Потому что оно, во-первых, своё, а во-вторых, развивается и оптимизируется.

В этом смысле я не понимаю MySQL, в котором, оказывается, "всё лучшее" делается через InnoDB, а по умолчанию имеем "исторический" MyISAM, тормозной и нефункциональный. К слову, перенос даннвх с m 3.23 на m 4.х мне пришлось делать через дамп - бинарная совместимость была задекларирована, но, как выяснилось, херово реализована.

> зачем мне беспокоиться про vacuum?

А действительно - зачем? Назови хотя бы одну причину. :)

> что за чертовщина с кодировками и collate?

One LC_COLLATE/LC_CTYPE per database cluster?
А что, реально хочется развести бардак с кучей разных кодировок в базе?
По-моему, жизненное применение имеют только случаи "в базе одна кодировка" и "в базе UTF-8".
Если хочется много разных букв, бери UTF-8.

> сколько времени надо на переход с версии 7.x на 8.x?

dump/initdb/restore

> имеет ли значение производительность системы?

разумеется. это не контрольный вопрос, а риторический.

> им слабó реализовать LIMIT #,# или они хотят «построить» всех остальных?

кто такие "остальные"? MySQL, что ли? лично я за ANSI, и нефиг тут разводить пиджин-SQL.

> кто, чёрт побери, придумал такую систему аутентификации?

1. Trust authentication
2. Password authentication
3. Kerberos authentication
4. Ident-based authentication
5. PAM authentication

с которой из них что-то не так? мне вот Kerberos не нравится.
с другой стороны, когда у тебя есть *end в виде PHP или Perl, что тебе до той аутентификации? оно ведь там уже реализовано.
создаёшь юзеров в базе и коннектишься.

А, тьфу, забыл

[zmeuka.livejournal.com]

Не нравится - не ешь
но не смей подозревать меня в нереальности. :)

Эх.

[kastaneda]

Чтоб ещё я выбирал, с чем работать приходится...

[zmeuka.livejournal.com]

Гм. Насколько я помню, в этом отношении ты как раз довольно переборчивый.
Или кто-то сделал мафиозное предложение?

[kastaneda]

Не мафиозное. По большому счёту, в БД можно особо глубоко не лезть и сконцентрироваться на бочке говна небольшом AJAXовом приложении. Но так уж получилось.

О переборчивости: не поверишь, собираюсь заехать на Петровку и купить пару кило макулатуры про Java. Хотя профориентацию менять не намерен.

[samokhvalov.livejournal.com]

В целом, со всеми ответами других комментаторов согласен, одно только небольшое дополнение:
в стандарте SQL нет аналога LIMIT/OFFSET. Есть только упоминание в заметках в конце текста стандарта -- о том, что это очень плохо, не иметь подобной вещи :-)

По поводу LIMIT x, y -- а чем этот mySQL-изм лучше-то? Наоборот, хуже. Читабельность хуже, новички могут ошибаться и путать x с y. Фраза про "построить" соврешенно не понятна -- какой смысл ориентироваться на нестандартные вещи MySQL? Вы в курсе "маразмов" этой СУБД -- например, подхода к работе с датами? Или, может, вы думаете, что Постгрес очень молодая СУБД? (Если так, очень рекомендую прочитать http://www.sai.msu.su/~megera/postgres/talks/what_is_postgresql.html).

Чтобы любить Постгрес, нужно любить реляционные СУБД. Я использовал в работе 5 различных, включая MS SQL и Oracle (более года работа для каждого). Постгрес был для меня своего рода открытием. СУБД очень "правильная", к юзерам близка как ни одна другая -- просто попробуйте получить советы по своим проблемам в списках рассылки (pgsql-general или, если хочется русского, pgsql-ru-general: http://www.postgresql.org/community/lists/)

Приглашаю посетить секцию "Базы данных" на РИТ 2007 (http://rit2007.ru) -- обсудим разные СУБД, потолкуем :-)

[samokhvalov.livejournal.com]

Вот, не поленился слазить в SQL:2003 (WG3:HBA-003 = H2-2003-305 = 5WD-02-Foundation-2003-09, WD 9075-2 "SQL/Foundation"), в конце приведены комменты в разделе "Language Opportunities" (я бы очень удивился, если бы в качестве примера приводили MySQL -- СУБД совершенно неразвитую в тот момент, в 2003-м и ранее):

The following Language Opportunity has been noted:
Severity: Language Opportunity
Reference: P02, SQL/Foundation, No particular location
Source: Email from Troels Arvis, 2003-07-22

Language Opportunity:
Please consider adding a standardized way to limit the size of a result set. The majority of SQL
DBMSs seem to already to that to certain extends, but with different syntax.
I think it’s a shame that such a useful feature isn’t standardized: It’s more basic and simple
than objects, XML, etc. But still an issue which deserves some attention, I believe.
Limiting what parts of a result set is returned is - of course - only useful if the result set is
ordered. If it’s ordered, it’s very practical to be able to ask that that - e.g. - only a maximum
of X rows are returned, perhaps after having skipped Y rows in the result set. I often use it in
paginated data listings where it’s useless to work with the complete result set.

In PostgreSQL, you can do:
select * from country order by id_numeric limit 5 offset 5;
SELECT id_numeric,iso_name
FROM country
ORDER BY id_numeric
LIMIT 30 OFFSET 60;
This way, I’ll get a maximum of 30 result set rows, after the system has skipped the first 60
rows.

Microsoft SQL Server has a somewhat similar approach:
SELECT TOP 30 id_numeric, iso_name
FROM country
ORDER BY id_numeric;
- but here you cannot specify an offset which makes the feature less useful.

There are several other implementations. Around the Web, you may see a large number of workarounds,
stored procedures and other over-complex machinery to try to handle the different
implementations (or emulate the operations when the products don’t have the feature).
I believe that something along the line of PostgreSQL’s syntax is readable and compact.

[kastaneda]

На РИТ точно не явлюсь, но за комментарий -- спасибо.
Да, я в курсе, много что в MySQL выглядит маразматично. SET NAMES "кодировка", MATCH-AGAINST и многое другое меня самого не радуют. Но, если уж спорить, то случай с LIMIT #,# очень характерен: граждане из PostgreSQL знают о таком синтаксисе, но не хотят его поддерживать, и это грустно. Ну на кой чёрт нужна их принципиальность?

[samokhvalov.livejournal.com]

Ну тогда надо и MS-овский "SELECT TOP n" поддерживать, верно? Так совсем грамматика замусорится, это плохо. Для вопросов совместимости есть стандарт. Места, которые он не покрывает, лучше не "флудить", а ждать латания дыр стандарта. А до той поры придерживаться только своего пути, который сложился исторически.

[samokhvalov.livejournal.com]

Кстати, SET NAMES -- из стандарта :-)
И в Постгресе тоже есть: "SET NAMES value is an alias for SET client_encoding TO value."
Вообще, стандарт SQL та ещё помойка, вот лучше его покритикуйте для начала :-)

[kastaneda]

Неплохо бы на досуге написать своё видение или ещё какой апокриф к SQL :)

оффтоп

[st-link.livejournal.com]

http://st-link.livejournal.com/337348.html ;)