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, скажем. Ну и пусть туда развивается, чо.

[metaclass.livejournal.com]

Все варианты аудита выглядят как говно. Что на триггерах, что в EF, что в ActiveRecord c papertrail.
Но на триггерах оно как минимум не зависит от клиента подключающегося к БД - хоть там сервер приложений, хоть расчетный сервис, хоть двухзвенка или юзер из консольного клиента БД подключился.

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

[dr-cha0s.livejournal.com]

Правильно! Бери Haskell, Persistent и Esquiletto.

[jakobz.livejournal.com]

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

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

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

[metaclass.livejournal.com]

Муахахаха, мастер-деталь это проклятая тема похуже аудита.

[ext_1684112 (from livejournal.com)]

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

[jakobz.livejournal.com]

Дай линку что-ли.

[ext_1684112 (from livejournal.com)]

http://plumqqz.livejournal.com/394579.html?thread=4580691#t4580691

[falcrum.livejournal.com]

Да нужны иногда триггера - только чтоб БД не грузили.

[ext_1684112 (from livejournal.com)]

>MSSQL

Вот тут вы сильно ошибаетесь. Если учесть возможность написания процедур на C# и таких вещей, как очереди сообщений прямо в базе, планировщик, и прочее, то MSSQL таки превосходит Постгрес.

[jakobz.livejournal.com]

А еще можно на полиэтиленовой обложке дневника обвести ручкой слово "дневник", чуть-чуть пальцем натянуть и получится "дневник дневник".

[ext_1684112 (from livejournal.com)]

Я вас не понимаю. Можете развернуть вашу мысль?

[jakobz.livejournal.com]

API к базе у этих "хранимок на C#" - оно такое же почти, как и внешнее API. Чем это будет отличаться от того чтобы писать логику во внешнем сервисе, чисто тем где этот сервис хостится?

[ext_1684112 (from livejournal.com)]

Положим, такая хранимка может принять сообщение из очереди и обрабатывать его, используя любую, самую изощренную логику, которую писать на pl/sql будет сильно муторно.

[jakobz.livejournal.com]

Любой отдельно стоящий код на .net может сделать ровно тоже самое.

[ext_1684112 (from livejournal.com)]

Не совсем то же самое. Доступ к базе изнутри базы работает как-бы заметно быстрее. Речь же идет о чем? Как запихать логику в базу. И у MS SQL на этот вопрос есть хороший ответ.

[jakobz.livejournal.com]

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

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

Я ничего не имею .net-а внутри базы, но это уже совсем не то. В postgres, к слову, можно вообще бинарники на сях внутрь совать.

[ext_1684112 (from livejournal.com)]

>один и тот же язык,
Воот! И есть мнение, что C# более человечен, чем plsql, и среда разработки под него нормальная.

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

[(Anonymous)]

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