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

[metaclass]

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

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

Comments

[plumqqz.livejournal.com]

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

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

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

[berezovsky.livejournal.com]

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

[plumqqz.livejournal.com]

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

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

[(Anonymous)]

Приплыли... 1) Вам уже раньше сказали 2) чтоб посрать я должен соорудить Байконур! Нахрен.

[berezovsky.livejournal.com]

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

[plumqqz.livejournal.com]

Конечно перемудрили. Зачем их возвращать? Хвала Всевышнему - когда он создавал числа, он создал их достаточно.

[metaclass.livejournal.com]

Не, потеря части ключей никого не волнует. Они и в случае генераторов-сиквенсов пропускаются при ошибках.

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

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

[plumqqz.livejournal.com]

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