возня с orm, часть 2
Sep. 18th, 2009 03:26 pm![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
wizzardоно вообще неплохо. работает. только вот мне как-то кажется, что компилить C# в AST, AST в SQL, SQL в query, query в план запроса (см. серию постов ![[livejournal.com profile]](https://www.dreamwidth.org/img/external/lj-userinfo.gif){kind=small}
zabivator про устройство БД) - это какой-то оверкилл. просадка перформанса в дебаге оч существенная, по крайней мере.
предметная область обычно лучше мапится на динамическое ОО (спорно, конечно, но что делать, если например взяли и ввели проездные билеты на кол-во поездок, в дополнение к проездным на определенный срок)
так вот, кажется, что идеальное API для БД и для работы с файлами – это что-то вроде коллекций, которые хранятся или в памяти, или на носителе, и имеет copy-by-reference (для RAM или private storage) или copy-by-value (для сьемных носителей) семантику. ну и индексами они могут заведовать, чего уж там, это полезно :)
что-то подобное, кажется, приветствуют ребята из Фантома (dz и т.д.)
UPD: ну, не все так радужно, судя по совместному с ev_genus экспириенсу, подводных камней там тонны :) в основном потому, что если выбросить из головы процессы, файлы и потоки, то надо всё заново придумывать. как говорится, техника безопасности написана кровью.
![[identity profile]](https://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
no subject
Date: 2009-09-18 12:51 pm (UTC)> идеальное API для БД и для работы с файлами – это что-то вроде коллекций
Один из уровней ADO, который ниже ICommand -- смотрели?
Вроде как даже реализовано в MS SQL Server, не уверен, что выдано наружу.
Оно-то может и легко, только поддерживать (изменять при изменении БД, напр.) такой навигационный код... впрочем, часто не хуже, чем SQL-основанный.
Ностальгия -- писать на MS Access-подобном.
no subject
Date: 2009-09-18 01:32 pm (UTC)У меня сейчас Mono, Linux, SQLite локально и постгрес на удаленном сервере, и есть подозрения что через неделю этим же бинарникам придется научиться работать на WinMobile. Так что секас с совместимостью еще тот.
no subject
Date: 2009-09-18 01:41 pm (UTC)no subject
Date: 2009-09-18 01:25 pm (UTC)Но и от реляционных всяких фич, а так же того, что реляционные БД наиболее распространены, отказываться не хочется, а то можно было бы пойти самым тупым путем - сериализовать объект и ложить его в блоб, часто это самый простой путь.
no subject
Date: 2009-09-18 01:36 pm (UTC)а вообще +1
no subject
Date: 2009-09-18 08:52 pm (UTC)это классно до тех пор, пока не появляется необходимость искать по ключу, отличному от первичного. а она появляется почти всегда.
no subject
Date: 2009-09-18 08:56 pm (UTC)Но тогда мрак начинается когда надо обновить множество объектов одним запросом, уже одним SQL тут не обойдешься.
no subject
Date: 2009-09-18 09:01 pm (UTC)во-от, а потом народ вдруг осеняет: а зачем дублировать-то? и блоб исчезает.
ну и кроме того - дополнительная мутота с десериализацией при изменении схемы.
no subject
Date: 2009-09-18 09:02 pm (UTC)no subject
Date: 2009-09-18 09:04 pm (UTC)no subject
Date: 2009-09-18 09:25 pm (UTC)1. blob-like (но не opaque) обьекты в духе (больших) текстов, изображений (которые мы обрабатываем, а не просто храним)
2. графоподобные и деревоподобные структуры большой глубины (декартово произведение не очень рулит при этом)
3. nested-hashtable-like обьекты (json, xml, etc), но это как бы сводится к п.2
no subject
Date: 2009-09-18 11:27 pm (UTC)3 - json и xml - это форматы представления данных (любых), а не тип/класс объектов.
моё предыдущее удивление было связано с тем, что я пытался понять, как ваш вопрос связан с предыдущим обсуждением, а теперь я понял, что никак.
no subject
Date: 2009-09-18 11:31 pm (UTC)оно связано с общей тематикой поста "реляционки как-то недостаточно гибкие". а с обсуждением - а если в блобе было дерево? как тогда изменится схема, чтобы изничтожить блоб?
no subject
Date: 2009-09-18 11:56 pm (UTC)no subject
Date: 2009-09-18 11:57 pm (UTC)no subject
Date: 2009-09-18 03:37 pm (UTC)Динамические или статическое ПО - вопрос дистрибьюции. При правильном проектировании динамическая сборка проекта (builder + factory + another similar) аналогична статической (прогон DSL'ей).
ACID? Multipass algs? Всё что есть в СУБД, придётся повторить, лишь в меньшем объёме.
no subject
Date: 2009-09-18 03:54 pm (UTC)Это-то и останавливает. Жду релиза software transactional memory какой-нибудь.
no subject
Date: 2009-09-18 04:00 pm (UTC)От простого - к сложному, наращивать и документировать инструментарий
no subject
Date: 2009-09-18 08:47 pm (UTC)> C# в AST, AST в SQL, SQL в query, query в план запроса
что такое query здесь?
на самом деле всё ещё хуже: C# в AST, AST в SQL, SQL обратно в AST, но уже на сервере. то есть если бы они сподобились сделать интерфейс, принимающий прямо AST, то на два шага можно было бы всё сократить.
no subject
Date: 2009-09-18 08:48 pm (UTC)no subject
Date: 2009-09-18 08:55 pm (UTC)обычно sql, query, sql query - синонимы. а вот AST - это то, что получилось после распаршивания.
no subject
Date: 2009-09-18 08:50 pm (UTC)http://zabivator.livejournal.com/329881.html
no subject
Date: 2009-09-18 08:56 pm (UTC)no subject
Date: 2009-09-19 12:15 am (UTC)no subject
Date: 2009-09-19 12:17 am (UTC)no subject
Date: 2009-09-19 08:34 am (UTC)no subject
Date: 2009-09-19 10:44 am (UTC)no subject
Date: 2009-09-21 08:54 pm (UTC)http://zabivator.livejournal.com/330306.html?thread=7005250&format=light#t7005250 - два
Мне почти достаточно информации, чтобы сделать выводы =)
Вот ещё одна такая веточка - и всё станёт на свои места.
no subject
Date: 2009-09-19 09:32 am (UTC)no subject
Date: 2009-09-19 09:44 am (UTC)Чего для просветления почитать...
Гарсиа-Молина читал - не помогло
Кормана читал - не помогло
Стивенсона читал - тоже не помогло
Криса Касперски читал - тоже не помогло
...ещё список...
Чего же делать для исправления такого кошмара, о гуру, без каши и пустоты в голове?