metaclass: (Default)
metaclass ([personal profile] metaclass) wrote2012-10-23 11:27 am

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

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

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

[identity profile] maxdz.livejournal.com 2012-10-23 07:33 pm (UTC)(link)
Я написал в P.S. - инсерты должны выполняться только через отдельную функцию, а не напрямую. Это может быть хранимая процедура (но такое не есть хорошо), а может быть функция бизнес-логики.

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

[identity profile] berezovsky.livejournal.com 2012-10-23 07:47 pm (UTC)(link)
в пределе это может тормозить, и надо пользоваться средствами конкретной БД

[identity profile] maxdz.livejournal.com 2012-10-23 07:51 pm (UTC)(link)
Чтобы не тормозило - есть т.н. "аппликэйшн сервера". Но при этом, вынесение всей непосредственной работы с БД на уровень бизнес-логики из клиентов, даёт массу преимуществ, которые с SQL запросами в коде клиентов никак не реализуются.

Да и разница в быстродействии не так уж велика, если вообще (и нивелируется недостатками такой "2-уровневой" архитектуры).

П.С. Единственный легитимный вариант, когда SQL запросы имеют право быть в коде клиента - если клиент работает с выделенной/персональной базой данных, в экслюзивном режиме.
Edited 2012-10-23 19:55 (UTC)

[identity profile] berezovsky.livejournal.com 2012-10-23 08:04 pm (UTC)(link)
Чтобы не тормозило, все производители БД должны объединиться в один и сделать одну нормальную БД. При этом не пользоваться преимуществами монополии и не давать повода клепать новые идиотские БД. По мере того как это будет происходить, усилия будут направляться на улучшение единственной БД, а не размножение новых. Но сейчас действует принцип закулисы "разделяй и властвуй", что и приводит к чувству фрустрации по отношению к эволюции баз.

[identity profile] maxdz.livejournal.com 2012-10-23 08:09 pm (UTC)(link)
Гы-гы. Идеальных/универсальных решений не бывает. Кому-то хочется от БД одного, кому-то иного. Да и конкуренция вынуждает производителей быть в тонусе и делать всё лучшие решения, вместо говна.

Так что, незачем требовать таких глупостей, как единая БД от всех и для всех. :)
Edited 2012-10-23 20:10 (UTC)

[identity profile] berezovsky.livejournal.com 2012-10-23 08:18 pm (UTC)(link)
философия новой эры же :-(