![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
Postgres 9.3
Посмотрел, чего добавили в Postgres новый.
Все огорчает, т.к. никак не коррелирует с другими СУБД, соответственно - использовал новую фичу - прибил себя гвоздями к постгресу.
Всякие там json-типы данных, да какие-то lateral join да внешние источники данных.
Даже не знаю, имеет ли смысл углублятся в эти нетривиальные SQL-расширения, потому как сделать все методом "сгенерил стандартный SQL и потом обработал результат на более мирном языке" выглядит более future-proof. Это что касается чтения данных.
А в плане записи - вообще все хреново, триггера везде разные, автоинкременты разные, глаза б этого всего не видели, но реализация "вся логика в сервере приложений или клиенте" выглядит еще более неприятно.
Все огорчает, т.к. никак не коррелирует с другими СУБД, соответственно - использовал новую фичу - прибил себя гвоздями к постгресу.
Всякие там json-типы данных, да какие-то lateral join да внешние источники данных.
Даже не знаю, имеет ли смысл углублятся в эти нетривиальные SQL-расширения, потому как сделать все методом "сгенерил стандартный SQL и потом обработал результат на более мирном языке" выглядит более future-proof. Это что касается чтения данных.
А в плане записи - вообще все хреново, триггера везде разные, автоинкременты разные, глаза б этого всего не видели, но реализация "вся логика в сервере приложений или клиенте" выглядит еще более неприятно.
no subject
углубляться в расширения, если идти путём "сгенерить стандартный sql", не нужно.
если же идея обработки данных чуть превосходит "сгенерить стандартный sql и обработать клиентом/аппсервером", можно пойти в сторону аналитических/оконных функций, других специфических для бд функций, это будет точно быстрее и, вероятно, безглючнее.
если делать быстрые решения, в том числе не требующие пересылки данных между бд и клиентом/аппсервером, то уже появляются хранимые процедуры. А на этом этапе, когда с базой данных определились, и требуется производительность, как-то пофиг на различия между бд.
а вот останавливаться на уровне odbc -- не стоит. Базы данных слишком разные, чтобы с ними можно было бы одинаково работать. Вся эта транзакционная ёбынь, коммиты, select for update, явные локи -- всё это надо писать с учётом специфики бд. Универсально не получится. Точнее, получится, но будет хуйня.
no subject
Всякое нетривиальное, конечно, приходится делать родными средствами БД.
no subject
Понятно, что стандартов на хранимки, триггеры и автоинкременты нет, но их и не будет.
Был у меня проектик, где я из coq хотел сделать едсл, транслятор в схему бд и в plpgsql, а там и в другие бд, но с ним никто не помогает, поэтому тут я решения не предложу.
Да и нужно ли решение, если почти никто не меняет базу данных обычно? (хотя бы потому, что хитрая логика делается родными средствами.)
no subject
no subject
no subject
Очень круто. С удовольствием бы помог, но я даже Хаскель не осилил.
Мне кажется, ужас разработчиков от plpgsql порождается отсутсвием нормальных инструментов разработки. Даже за деньги их нет. PgAdmin - он же хуже ТурбоПаскаля, тот хотя бы не давал обращаться к несуществующим переменным. А где IntelliSence? Где возможность выделить несколько запросов и автоматом их вынести в отдельную функцию? Где нэймспейсы, хоть какие-нибудь? Где глобальный поиск по коду? Даже отобрать права на сущности так просто нельзя, нужно запрос писать. Дать - можно, а забрать - хрен.
no subject
Мне интересно, хотя не столько для портабельности, сколько просто нравится идея писать под постгрес на Coq.
А это где-нибудь выложено?
no subject
Если интересно даже несмотря на вышеизложенное, могу выложить в приватную репку на битбакете и дать туда доступ.
Публично не хочу, ёбаный стыд там. А если хоть какая-то помощь будет -- буду рад. Потом-то, как будет что-то работать, можно будет выкладывать публично и лицензировать под какой-нибудь свободной лицензией.
no subject
Обещать активную помощь не могу, так как пока ни в чём конкретном не планирую применять, но, может быть, потихоньку-понемножку чего-нибудь да сделается...
no subject
У меня тоже сейчас нет применений, но были и будут.
Если интересно, что именно я хотел сделать этим проектом, со мной можно связаться через мыло gdsfh1 на гмейле, я опишу основные концепции (скорее даже в репку закоммичу), заодно там же можно было бы обсудить, как вообще эта хрень должна работать. Идеи нужны, вот чо.
no subject
Моя почта alexej.golovko@gmail.com,завтра постараюсь выйти на связь и спросить что-нибудь осмысленное (а не просто повторить вопрос, как вообще эта хрень должна работать).
no subject