Чувствую, что несу чушь,
но не могу отделаться от ощущения, что с эволюцией баз данных нас очень сильно наебали.
Это по поводу этого: http://plumqqz.livejournal.com/323506.html
Меня очень сильно бесит расхождение технологий: с одной стороны, классические СУБД, с другой NoSQL, с третьей - всякие in-memory распределенные базы, с четвертой - всякие аналитические БД с column storage, сжатием данных и перекосом в сторону чтения типа vertica, sybase iq или забиваторской QD. Плюс еще всякие datomic до которой я никак добраться не могу.
Все это, очевидно, между собой мало совместимо, решает разные задачи, требует каких-то дурных миграцией данных между собой и превращает работу с большим количеством данных в тыкву, потому что вместо одного толкового решения существует десяток решений разной степени безумности, требующих интеграции.
Это по поводу этого: http://plumqqz.livejournal.com/323506.html
Меня очень сильно бесит расхождение технологий: с одной стороны, классические СУБД, с другой NoSQL, с третьей - всякие in-memory распределенные базы, с четвертой - всякие аналитические БД с column storage, сжатием данных и перекосом в сторону чтения типа vertica, sybase iq или забиваторской QD. Плюс еще всякие datomic до которой я никак добраться не могу.
Все это, очевидно, между собой мало совместимо, решает разные задачи, требует каких-то дурных миграцией данных между собой и превращает работу с большим количеством данных в тыкву, потому что вместо одного толкового решения существует десяток решений разной степени безумности, требующих интеграции.
no subject
Как сказано оратором выше, одним запросом берётся максимальный Id таблицы (для этого есть специальная аггрегатная функция, которая в ANSI стандарте), а потом в программе генерируется следующий уникальный Id = полученный максимальный Id + 1 и с таким Id делается вожделенный инсерт.
Очень сложно? :)
no subject
no subject
П.С. Ок, атомарности генерации Id и инсерта в таком случае на уровне СУБД не обеспечивается - но атомарность обеспечат инсерты, только через отдельную функцию бизнес-логики и никак иначе.
no subject
смотрите картину:
клиент 1: select max(id) from table
клиент 2: select max(id) from table
клиент 1: insert into table(id) values(...)
клиент 2: insert into table(id) values(...) -> PK violation
если делать блокировку - то транзакции перестают параллельно выполняться, и ждут друг друга, из-за чего производительность превращается в тыкву.
далее, select max(id) не работает мгновенно в MVCC архитектуре - ему нужно выяснить, "какую из версий таблицы я вижу". Надо бы проверить это дело в MSSQL и Postgresql, возможно, там что-то заоптимизировано на эту тему.
В принципе, достаточно красивый вариант предложил крокодил - брать из таблицы секвенсов каждому потоку-клиенту пул ID и затем его расходовать. Если не нужен монотонный рост ID то это вполне ок решение.
no subject
Когда несколько клиентов имеют возможность делать апдейты/инсерты в БД, напрямую (минуя бизнес-логику, с единообразной организацией/валидацией апдейта/инсерта) - это, в любом случае, нехорошо.
no subject
no subject
Да и разница в быстродействии не так уж велика, если вообще (и нивелируется недостатками такой "2-уровневой" архитектуры).
П.С. Единственный легитимный вариант, когда SQL запросы имеют право быть в коде клиента - если клиент работает с выделенной/персональной базой данных, в экслюзивном режиме.
no subject
no subject
Так что, незачем требовать таких глупостей, как единая БД от всех и для всех. :)
no subject
no subject
Никто максега травить не будет, не наговаривайте. Грех это. Но вот выражение "Нет никакой выборки. select max(Id) - это запрос, который в индексированной по Id таблице выполняется за миг." мне понравилось - за незамутненность и характерность.
no subject
Ок, не за миг - за одну миллисекунду. Так устроит?
no subject
Так как вы не женщина, насколько я понимаю, то высказывание про хорошенькую нужно опустить.
no subject