Чувствую, что несу чушь,
Oct. 23rd, 2012 11:27 am![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
metaclassно не могу отделаться от ощущения, что с эволюцией баз данных нас очень сильно наебали.
Это по поводу этого: 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 до которой я никак добраться не могу.
Все это, очевидно, между собой мало совместимо, решает разные задачи, требует каких-то дурных миграцией данных между собой и превращает работу с большим количеством данных в тыкву, потому что вместо одного толкового решения существует десяток решений разной степени безумности, требующих интеграции.
![[identity profile]](https://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
no subject
Date: 2012-10-23 11:21 am (UTC)no subject
Date: 2012-10-23 11:23 am (UTC)no subject
Date: 2012-10-23 11:31 am (UTC)2) вставляем запись в таблицу
3) возвращаем ID
Все ли СУБД поддерживают это в одном запросе?
Можно, конечно, сделать тремя запросами с клиента в одной транзакции, только потом стыдно будет на ORM за 1+N запросов псить :)
no subject
Date: 2012-10-23 11:36 am (UTC)Ну, во-первых, двумя - зачем и куда возвращать уже известный клиенту id лично мне не очень ясно. Во-вторых, это запросы о-очень легкие. В-третьих, незачем генерить ид каждый раз - могут быть проблемы с конкурентностью.
no subject
Date: 2012-10-23 11:40 am (UTC)no subject
Date: 2012-10-23 06:05 pm (UTC)no subject
Date: 2012-10-23 07:13 pm (UTC)Как сказано оратором выше, одним запросом берётся максимальный Id таблицы (для этого есть специальная аггрегатная функция, которая в ANSI стандарте), а потом в программе генерируется следующий уникальный Id = полученный максимальный Id + 1 и с таким Id делается вожделенный инсерт.
Очень сложно? :)
no subject
Date: 2012-10-23 07:15 pm (UTC)no subject
Date: 2012-10-23 07:17 pm (UTC)П.С. Ок, атомарности генерации Id и инсерта в таком случае на уровне СУБД не обеспечивается - но атомарность обеспечат инсерты, только через отдельную функцию бизнес-логики и никак иначе.
no subject
Date: 2012-10-23 07:29 pm (UTC)смотрите картину:
клиент 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
Date: 2012-10-23 07:33 pm (UTC)Когда несколько клиентов имеют возможность делать апдейты/инсерты в БД, напрямую (минуя бизнес-логику, с единообразной организацией/валидацией апдейта/инсерта) - это, в любом случае, нехорошо.
no subject
Date: 2012-10-23 07:47 pm (UTC)no subject
Date: 2012-10-23 07:51 pm (UTC)Да и разница в быстродействии не так уж велика, если вообще (и нивелируется недостатками такой "2-уровневой" архитектуры).
П.С. Единственный легитимный вариант, когда SQL запросы имеют право быть в коде клиента - если клиент работает с выделенной/персональной базой данных, в экслюзивном режиме.
no subject
Date: 2012-10-23 08:04 pm (UTC)no subject
Date: 2012-10-23 08:09 pm (UTC)Так что, незачем требовать таких глупостей, как единая БД от всех и для всех. :)
no subject
Date: 2012-10-23 08:18 pm (UTC)no subject
Date: 2012-10-24 06:55 am (UTC)Никто максега травить не будет, не наговаривайте. Грех это. Но вот выражение "Нет никакой выборки. select max(Id) - это запрос, который в индексированной по Id таблице выполняется за миг." мне понравилось - за незамутненность и характерность.
no subject
Date: 2012-10-25 10:54 am (UTC)Ок, не за миг - за одну миллисекунду. Так устроит?
no subject
Date: 2012-10-25 11:00 am (UTC)Так как вы не женщина, насколько я понимаю, то высказывание про хорошенькую нужно опустить.
no subject
Date: 2012-10-25 11:12 am (UTC)