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

[metaclass]

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

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

Comments

[plumqqz.livejournal.com]

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

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

[(Anonymous)]

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

[berezovsky.livejournal.com]

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

[plumqqz.livejournal.com]

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

[metaclass.livejournal.com]

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