Postgres 9.3

[metaclass]

Посмотрел, чего добавили в Postgres новый.
Все огорчает, т.к. никак не коррелирует с другими СУБД, соответственно - использовал новую фичу - прибил себя гвоздями к постгресу.
Всякие там json-типы данных, да какие-то lateral join да внешние источники данных.

Даже не знаю, имеет ли смысл углублятся в эти нетривиальные SQL-расширения, потому как сделать все методом "сгенерил стандартный SQL и потом обработал результат на более мирном языке" выглядит более future-proof. Это что касается чтения данных.
А в плане записи - вообще все хреново, триггера везде разные, автоинкременты разные, глаза б этого всего не видели, но реализация "вся логика в сервере приложений или клиенте" выглядит еще более неприятно.

Comments

[jakobz.livejournal.com]

А зачем тебе триггера, кстати? Мы вот недавно createdby/modifiedby и аудит с историей изменений к тому же Entity Framework приделали, все в одной функции лежит, еды не просит. При желании все это можно вообще куда-нибудь в другую базу лить, например. Думаю такое же проделывается на любом языке в нижнем уровне data-layer, безотносительно даже ORM-ки.

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

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

[kranov.livejournal.com]

Я видел и админил бд с самописным софтом заточенным под конкретную субд (информикс, оракл), с покупным заточенным, и с универсальным erp (baan, sap), сейчас покупной заточенный (процессинг, сотни тыс. карт и тысячи устройств) и самописный (абс, 1500 пользователей), базы соответственно терабайтные.
Вот что я имею сказать, заточенное, захинтованное в усмерть (регулярно приносят хачить запросы в которых 70 таблиц и 4 A4 длиной,надо чтоб работал за секунду) и использующее хаки конкретной субд, отлично летает на говне: 1сокет, 8ядер, 30гиг памяти, 16дисков.
Незаточенное, типа sap, легко жрало память 48 гиг на сервер приложений, обслуживающий 3-х пользователей, 50 серверов приложений на 5 тыс. пользователей, 200 дисков, 512Гиг у несколько нод субд, две ibm p795, и тооооорррррммозило.

[gds.livejournal.com]

lateral -- из sql-стандарта, его выбросим тут.

углубляться в расширения, если идти путём "сгенерить стандартный sql", не нужно.

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

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

а вот останавливаться на уровне odbc -- не стоит. Базы данных слишком разные, чтобы с ними можно было бы одинаково работать. Вся эта транзакционная ёбынь, коммиты, select for update, явные локи -- всё это надо писать с учётом специфики бд. Универсально не получится. Точнее, получится, но будет хуйня.

[(Anonymous)]

>но реализация "вся логика в сервере приложений или клиенте" выглядит еще более неприятно.

Вся логика в сервере приложений - это самая каноничная реализация. От БД надо лишь хранилище и SQL-92.

[besm6.livejournal.com]

"Что добавили нового" и должно быть несовместимым, потому что совместимое - это SQL92 как максимум, а всё оттуда добавлено не позже шестерки.

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

[norguhtar.livejournal.com]

Там сейчас добавили в репликации весьма клевую фичу ремастеринг штатными средствами.