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

[metaclass]

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

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

Comments

[metaclass.livejournal.com]

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

[nicka-startcev.livejournal.com]

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

[nicka-startcev.livejournal.com]

запад видим, восток не видим, да.

[(Anonymous)]

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

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

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

[metaclass.livejournal.com]

ADO сам по себе вроде не умеет же?

[plumqqz.livejournal.com]

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

[gds.livejournal.com]

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

[plumqqz.livejournal.com]

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

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

[gds.livejournal.com]

вставляется знамо что, но не обязанное быть уникальным.

про генератор -- по силам, конечно, но речь была про стандарт. Конечно, мне никуда не впёрлось перетаскивать программу с одной субд на другую, поэтому мне неактуально, но стандарт однако не даёт способа узнать последний вставленный id.

[plumqqz.livejournal.com]

вставляется знамо что, но не обязанное быть уникальным.
Если вставляется то, что не является уникальным, то нахера оно вообще вставляется? Типа дублирование - ну вроде как для надежности? Как написал какой-то руководитель, "пришлите мне четыре прозрачных однопиксельных гифа".

про генератор -- по силам, конечно, но речь была про стандарт.
Я, собственно, про стандарт и пишу - т.е. написать собственными силами, используя стандартный sql-92, генератор айдюков не по силам. Ок, ясно.

[metaclass.livejournal.com]

Писать самодельный генератор ID? Срочно делитесь тайным знанием.

[(Anonymous)]

Что еще написать? может собственную СУБД? Нахрен она такая нужна которая обычную задачу не делает?

[plumqqz.livejournal.com]

Скажите, а вы хорами имена объектов не шифруете?

[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]

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

[metaclass.livejournal.com]

4 разных, не сводимых друг к другу простой заменой метода. Вижу.

[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