Postgres 9.3
Sep. 10th, 2013 06:03 pm![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
metaclassПосмотрел, чего добавили в Postgres новый.
Все огорчает, т.к. никак не коррелирует с другими СУБД, соответственно - использовал новую фичу - прибил себя гвоздями к постгресу.
Всякие там json-типы данных, да какие-то lateral join да внешние источники данных.
Даже не знаю, имеет ли смысл углублятся в эти нетривиальные SQL-расширения, потому как сделать все методом "сгенерил стандартный SQL и потом обработал результат на более мирном языке" выглядит более future-proof. Это что касается чтения данных.
А в плане записи - вообще все хреново, триггера везде разные, автоинкременты разные, глаза б этого всего не видели, но реализация "вся логика в сервере приложений или клиенте" выглядит еще более неприятно.
Все огорчает, т.к. никак не коррелирует с другими СУБД, соответственно - использовал новую фичу - прибил себя гвоздями к постгресу.
Всякие там json-типы данных, да какие-то lateral join да внешние источники данных.
Даже не знаю, имеет ли смысл углублятся в эти нетривиальные SQL-расширения, потому как сделать все методом "сгенерил стандартный SQL и потом обработал результат на более мирном языке" выглядит более future-proof. Это что касается чтения данных.
А в плане записи - вообще все хреново, триггера везде разные, автоинкременты разные, глаза б этого всего не видели, но реализация "вся логика в сервере приложений или клиенте" выглядит еще более неприятно.
![[identity profile]](https://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
no subject
Date: 2013-09-10 03:11 pm (UTC)Короче, как по мне, если уж не пихать логику в базу, то не пихать ее туда совсем.
Я postgres не трогал, но вообще оно выглядит как самодостаточная штука как раз для того, чтобы в нее сувать всю логику. В отличии от тех же MySQL или MSSQL, скажем. Ну и пусть туда развивается, чо.
no subject
Date: 2013-09-10 03:28 pm (UTC)Но на триггерах оно как минимум не зависит от клиента подключающегося к БД - хоть там сервер приложений, хоть расчетный сервис, хоть двухзвенка или юзер из консольного клиента БД подключился.
И на любом языке это проделывается либо неудобно, либо неподдерживаемо, либо непригодно к использованию, ибо задача проклятая и в общем случае решаема только при использовании дикой функциональщины с иммутабельностью и линзами.
no subject
Date: 2013-09-10 03:56 pm (UTC)no subject
Date: 2013-09-10 06:05 pm (UTC)А по факту имеем API: входные данные отпарсить смогут только эти твои пауки, а выходные - вообще небось пропиетарны и читаются только сишными либами от вендора.
Я уже даже и не говорю, что уже 40 лет этой херне, а master-detail хоть как-то стандартно и разумно ни из одной базы прочитать нельзя.
no subject
Date: 2013-09-10 06:15 pm (UTC)no subject
Date: 2013-09-11 06:07 am (UTC)Крокодил же недавно демонстрировал - выброка из базы списка курсоров.
no subject
Date: 2013-09-11 10:38 am (UTC)no subject
Date: 2013-09-11 12:51 pm (UTC)no subject
Date: 2013-09-10 04:27 pm (UTC)no subject
Date: 2013-09-11 06:05 am (UTC)Вот тут вы сильно ошибаетесь. Если учесть возможность написания процедур на C# и таких вещей, как очереди сообщений прямо в базе, планировщик, и прочее, то MSSQL таки превосходит Постгрес.
no subject
Date: 2013-09-11 10:41 am (UTC)no subject
Date: 2013-09-11 11:58 am (UTC)no subject
Date: 2013-09-11 12:23 pm (UTC)no subject
Date: 2013-09-11 12:45 pm (UTC)no subject
Date: 2013-09-11 12:51 pm (UTC)no subject
Date: 2013-09-11 12:55 pm (UTC)no subject
Date: 2013-09-11 01:23 pm (UTC)Логику в базу запихивают потому что в чем-то это удобнее, чем писать снаружи: один и тот же язык, все на виду, можно подхачить не отходя от кассы.
Я ничего не имею .net-а внутри базы, но это уже совсем не то. В postgres, к слову, можно вообще бинарники на сях внутрь совать.
no subject
Date: 2013-09-11 06:39 pm (UTC)Воот! И есть мнение, что C# более человечен, чем plsql, и среда разработки под него нормальная.
А в постгрес можно яву засунуть, но что-то там такое... то ли одна ява-машина на все процессы, то ли еще какая дурь..
no subject
Date: 2013-09-11 11:07 am (UTC)no subject
Date: 2013-09-10 04:25 pm (UTC)Вот что я имею сказать, заточенное, захинтованное в усмерть (регулярно приносят хачить запросы в которых 70 таблиц и 4 A4 длиной,надо чтоб работал за секунду) и использующее хаки конкретной субд, отлично летает на говне: 1сокет, 8ядер, 30гиг памяти, 16дисков.
Незаточенное, типа sap, легко жрало память 48 гиг на сервер приложений, обслуживающий 3-х пользователей, 50 серверов приложений на 5 тыс. пользователей, 200 дисков, 512Гиг у несколько нод субд, две ibm p795, и тооооорррррммозило.
no subject
Date: 2013-09-10 04:44 pm (UTC)углубляться в расширения, если идти путём "сгенерить стандартный sql", не нужно.
если же идея обработки данных чуть превосходит "сгенерить стандартный sql и обработать клиентом/аппсервером", можно пойти в сторону аналитических/оконных функций, других специфических для бд функций, это будет точно быстрее и, вероятно, безглючнее.
если делать быстрые решения, в том числе не требующие пересылки данных между бд и клиентом/аппсервером, то уже появляются хранимые процедуры. А на этом этапе, когда с базой данных определились, и требуется производительность, как-то пофиг на различия между бд.
а вот останавливаться на уровне odbc -- не стоит. Базы данных слишком разные, чтобы с ними можно было бы одинаково работать. Вся эта транзакционная ёбынь, коммиты, select for update, явные локи -- всё это надо писать с учётом специфики бд. Универсально не получится. Точнее, получится, но будет хуйня.
no subject
Date: 2013-09-10 04:53 pm (UTC)Всякое нетривиальное, конечно, приходится делать родными средствами БД.
no subject
Date: 2013-09-10 05:01 pm (UTC)Понятно, что стандартов на хранимки, триггеры и автоинкременты нет, но их и не будет.
Был у меня проектик, где я из coq хотел сделать едсл, транслятор в схему бд и в plpgsql, а там и в другие бд, но с ним никто не помогает, поэтому тут я решения не предложу.
Да и нужно ли решение, если почти никто не меняет базу данных обычно? (хотя бы потому, что хитрая логика делается родными средствами.)
no subject
Date: 2013-09-10 05:36 pm (UTC)no subject
Date: 2013-09-10 05:56 pm (UTC)no subject
Date: 2013-09-11 06:13 am (UTC)Очень круто. С удовольствием бы помог, но я даже Хаскель не осилил.
Мне кажется, ужас разработчиков от plpgsql порождается отсутсвием нормальных инструментов разработки. Даже за деньги их нет. PgAdmin - он же хуже ТурбоПаскаля, тот хотя бы не давал обращаться к несуществующим переменным. А где IntelliSence? Где возможность выделить несколько запросов и автоматом их вынести в отдельную функцию? Где нэймспейсы, хоть какие-нибудь? Где глобальный поиск по коду? Даже отобрать права на сущности так просто нельзя, нужно запрос писать. Дать - можно, а забрать - хрен.
no subject
Date: 2013-09-19 06:04 pm (UTC)Мне интересно, хотя не столько для портабельности, сколько просто нравится идея писать под постгрес на Coq.
А это где-нибудь выложено?
no subject
Date: 2013-09-19 07:52 pm (UTC)Если интересно даже несмотря на вышеизложенное, могу выложить в приватную репку на битбакете и дать туда доступ.
Публично не хочу, ёбаный стыд там. А если хоть какая-то помощь будет -- буду рад. Потом-то, как будет что-то работать, можно будет выкладывать публично и лицензировать под какой-нибудь свободной лицензией.
no subject
Date: 2013-09-21 10:04 am (UTC)Обещать активную помощь не могу, так как пока ни в чём конкретном не планирую применять, но, может быть, потихоньку-понемножку чего-нибудь да сделается...
no subject
Date: 2013-09-21 11:11 am (UTC)У меня тоже сейчас нет применений, но были и будут.
Если интересно, что именно я хотел сделать этим проектом, со мной можно связаться через мыло gdsfh1 на гмейле, я опишу основные концепции (скорее даже в репку закоммичу), заодно там же можно было бы обсудить, как вообще эта хрень должна работать. Идеи нужны, вот чо.
no subject
Date: 2013-09-23 04:07 pm (UTC)Моя почта alexej.golovko@gmail.com,завтра постараюсь выйти на связь и спросить что-нибудь осмысленное (а не просто повторить вопрос, как вообще эта хрень должна работать).
no subject
Date: 2013-09-23 04:41 pm (UTC)no subject
Date: 2013-09-10 05:04 pm (UTC)Вся логика в сервере приложений - это самая каноничная реализация. От БД надо лишь хранилище и SQL-92.
no subject
Date: 2013-09-10 06:43 pm (UTC)Все, что добавляется с тех пор (и в другие базы данных, кроме, может быть, MySQL, где транзакции-то до сих пор толком не освоили) - средства для унесения логики приложения в БД, т.е. фактически развитие внутреннего языка программирования и библиотек. О совместимости в этом районе думать еще рано, поскольку нормальной математики под этим нет, и разработчики СУБД пока тыкаются в задачу как слепые котята. Было бы с чем совмещаться...
no subject
Date: 2013-09-11 06:15 am (UTC)no subject
Date: 2013-09-11 08:41 am (UTC)no subject
Date: 2013-09-11 04:34 am (UTC)