Чувствую, что несу чушь,

[metaclass]

но не могу отделаться от ощущения, что с эволюцией баз данных нас очень сильно наебали.
Это по поводу этого: http://plumqqz.livejournal.com/323506.html
Меня очень сильно бесит расхождение технологий: с одной стороны, классические СУБД, с другой NoSQL, с третьей - всякие in-memory распределенные базы, с четвертой - всякие аналитические БД с column storage, сжатием данных и перекосом в сторону чтения типа vertica, sybase iq или забиваторской QD. Плюс еще всякие datomic до которой я никак добраться не могу.

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

Comments

[nicka-startcev.livejournal.com]

>прикрутить ко всему этому SQL

какой именно SQL?
Диалектов этого сикеля - как собак нерезанных и по факту технический перенос чего угодно с одного на другой будет невозможен.

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

[metaclass.livejournal.com]

Да есть стандарт на него. Но козлопитоны производители сделали миллионы расширений или не целиком реализовали стандарт.

[nicka-startcev.livejournal.com]

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

А негодный стандарт, который все обходят по-разному, это и есть отсутствие стандарта.

[maxdz.livejournal.com]

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

[nicka-startcev.livejournal.com]

на диалекте F90 или C89 вполне можно написать код, который будет собираться почти везде и почти без гемора и даже работать. Значит, это хорошие, годные стандарты. Да, на них можно насрать, но зачастую это не требуется.

А вот с сикелем, как я понимаю, всё намного хужее и стандартный код будет убог до неприменимости.

[maxdz.livejournal.com]

>А вот с сикелем, как я понимаю, всё намного хужее и стандартный код будет убог до неприменимости.

Ты неправильно понимаешь.

[metaclass.livejournal.com]

Стандартного "почти" достаточно для работы. Процедурные расширения все равно айсед использовать запрещает :)

Впрочем, язык по современным стандартам убог до невозможности.

[nicka-startcev.livejournal.com]

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

А вот с SKL SQL, как я понимаю, такой трюк не проходит и замена оракал/мускул/мс приводит к весьма существенной попоболи, причем не только сразу, а плюс еще и отложенной.

[metaclass.livejournal.com]

А как в стандарте обстоят дела с двумя вещами: автоинкрементные поля/генераторы-секвенсы и возвращение результата последней DML операции (т.е. вернуть из insert/update значения полей, которые были автосгенерированы)?

[nicka-startcev.livejournal.com]

Вот все и решают, разными несовместимыми и непереносимыми способами.
А потом жалуются на пиздец.

[(Anonymous)]

Тоесть проблемы индейцев шерифа.... Дык в жопу такого шерифа. Я думал я один такой дурак, но вот вопль "автоинкрементные поля/генераторы-секвенсы и возвращение результата последней DML операции (т.е. вернуть из insert/update значения полей, которые были автосгенерированы"

Это уже не просто вопль. В отличае от меня этот человек что, то пишет и не первый год и у него такие вот вопросы.

Насчет DB2 ну не знаю. MySQL и MS SQL по сравнению с ним это уже не то.

[plumqqz.livejournal.com]

А, собственно, если так уж надо, то чего бы после инсерта-апдейта не запросить значения полей, которые были сгенерированы?

[gds.livejournal.com]

как это сделать при вставке в таблицу в случае отсутствия любого другого ограничения уникальности, кроме того, которое включает автогенерируемый столбец?

[plumqqz.livejournal.com]

То есть, если я правильно понимаю, в таблицу вставляется незнамо что? Странно как-то...

PS Написать собственный генератор айдюков, коли приспичило, как я смотрю, задача тоже непосильная.

[metaclass.livejournal.com]

insert into table ... values ... returning есть у Firebird, Oracle, Postgresql
SELECT SCOPE_IDENTITY() - mssql
LAST_INSERT_ID() - mysql
IDENTITY_VAL_LOCAL() - db2

[plumqqz.livejournal.com]

Ну вот видите же.

[(Anonymous)]

Причем очень смешно работает LAST_INSERT_ID() при многопоточности! Офигенно!

[w00dy.livejournal.com]

Обычно возвращать нужно только pk записи. А его можно генерировать на клиенте, тот же гуид например. Я так делаю и меня эти вопросы не волнуют.

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

[metaclass.livejournal.com]

GUID, да. 16 байт на PK, 16 байт в записях индексов и FK и прочих полей. Не уверен, что это гуманно.

[w00dy.livejournal.com]

Зато pk всегда есть на клиенте, и когда создаёте записи то можно просто впихнуть пачку insert-ов, а не городить выборку непонятно чего.

[volodymir-k.livejournal.com]

В стандарте используются таблицы вида "tablename : last_pk_value"
либо (при наличии оптимизации и точки контроля) делают select max(id) + 1 from table / retry on commit fail

> т.е. вернуть из insert/update значения полей, которые были автосгенерированы

это уровень API, а не SQL