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

[metaclass]

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

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

Comments

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

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

[gds.livejournal.com]

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

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

[plumqqz.livejournal.com]

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

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

[metaclass.livejournal.com]

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

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

[metaclass.livejournal.com]

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

[metaclass.livejournal.com]

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

[plumqqz.livejournal.com]

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

[w00dy.livejournal.com]

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

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

[plumqqz.livejournal.com]

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

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

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

[metaclass.livejournal.com]

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

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

[metaclass.livejournal.com]

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

[plumqqz.livejournal.com]

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

[nicka-startcev.livejournal.com]

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

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

[metaclass.livejournal.com]

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

[berezovsky.livejournal.com]

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

[maxdz.livejournal.com]

А нефиг пользоваться в SQL расширениями - и попоболи не будет. :)

[w00dy.livejournal.com]

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

[plumqqz.livejournal.com]

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

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

[arush-damage.livejournal.com]

Оригинал лучше:


Да и стих перед песней доставляет %)))

[veter-r-r.livejournal.com]

Он старый, но очень недобрый.

[veter-r-r.livejournal.com]

Я видел который работает. Правда он требовал под себя столько ресурсов, что там можно было кластер MySQL запустить и еще бы на пару ораклов осталось.

[falcrum.livejournal.com]

Да замена оракла на оракла часто приводит к ней же: скажем, 10-й и 11-й так по-разному могут строить планы запросов, что... :)