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

[metaclass]

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

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

Comments

[plumqqz.livejournal.com]

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

[gds.livejournal.com]

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

[plumqqz.livejournal.com]

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

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

[gds.livejournal.com]

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

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

[plumqqz.livejournal.com]

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

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

[metaclass.livejournal.com]

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

[plumqqz.livejournal.com]

Во, дожыле. Уже теперь и это - тайное знание. Стоит ли удивляться, что полеты на аэростатах начали считать полетами в космос?

Итак, делаем таблицо "хенератор" о двух полях - имя и валуй. Клиент, который хочет получить пачку айдюков для последующей вставки сначала отправляет запрос
begin transaction;
а потом
select * from "хенератор" where "имя"='thetable' for update;
а потом отмечает себе, что от (валуй+1 до валуй+дельта] - это его айдюки и он их может использовать, после чего говорит
update "хенератор" set "валуй"="валуй"+:дельта where "имя"='thetable';
а потом еще и
commit;

Так клиент может получить вдоволь айдюков, а я - поделиться нынешним тайным знанием.

[berezovsky.livejournal.com]

это по идее должно быть в атомарной транзакции внутри общей транзакции или пофиг?
в стандарте такое есть?

[plumqqz.livejournal.com]

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

в стандарте такое есть?
Что "такое"? Вышенаписанное вполне соответствует SQL92; а что там есть именно такой код - это я сомневаюсь.

[Дмитрий Васильев (from livejournal.com)]

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

[plumqqz.livejournal.com]

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

[metaclass.livejournal.com]

UPDATE Counters
SET @value = value = value + 1
WHERE counter = @counter
Закапываем. Работает только в MSSQL.

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

Ну напишите свой генератор.

[metaclass.livejournal.com]

1) генерируем ID
2) вставляем запись в таблицу
3) возвращаем ID

Все ли СУБД поддерживают это в одном запросе?
Можно, конечно, сделать тремя запросами с клиента в одной транзакции, только потом стыдно будет на ORM за 1+N запросов псить :)

[plumqqz.livejournal.com]

Можно, конечно, сделать тремя запросами с клиента в одной транзакции, только потом стыдно будет на ORM за 1+N запросов псить :)
Ну, во-первых, двумя - зачем и куда возвращать уже известный клиенту id лично мне не очень ясно. Во-вторых, это запросы о-очень легкие. В-третьих, незачем генерить ид каждый раз - могут быть проблемы с конкурентностью.

[metaclass.livejournal.com]

Да, идею понял.

[(Anonymous)]

Осталось только научиться генерить такие ID. UUID хороши но блин размер... И правила таких ID? Шел 2012 год, а Степаныч изучал модуль рандом....

[maxdz.livejournal.com]

А чем последовательные Id не подходят?

Как сказано оратором выше, одним запросом берётся максимальный Id таблицы (для этого есть специальная аггрегатная функция, которая в ANSI стандарте), а потом в программе генерируется следующий уникальный Id = полученный максимальный Id + 1 и с таким Id делается вожделенный инсерт.

Очень сложно? :)

[(Anonymous)]

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