wizzard

можно почитать больше и с картинками у Алексея - http://alexey.raga.name/

“- Теперь у меня есть на это ответ. Я знаю, что такое noSQL и покажу вам. Больше нет никакого смысла противопоставлять SQL и noSQL, теперь наступит мир, сказал Эрик.”

…Далее он всячески “наезжал” на язык SQL (а что, как архитектор MS SQL Server он легко может себе такое позволить) за отсутствие возможности композиции, отсутствие возможности рекурсии как таковой (да, есть теперь CTE, но это не то), за то, что тип результата не соответствует типу запроса, много и интересно ссылался на различных мировых светил и т.д.

…все законы и свойства, применимые к SQL-системам, дуально применимы к coSQL системам и наоборот. Взять ту же ссылочную целостность:
- в SQL ссылки направлены от родителя к детям, в coSQL – от детей к родителям;
- в SQL используется “внешняя” системы ссылок (объекты маркируются ID), в coSQL – внутренняя система (ссылки на сами объекты);
И так много, много пунктов.

Что из этого следует?
А то, что SQL и coSQL могут сосуществовать в одной экосистеме (и то, что этим занимается архитектор MS SQL Server уже является кое-каким намёком), а не являются “непримиримыми врагами”.
То, что (и Эрик это даже прямо сказал) обе эти системы могут иметь некий общий “интерфейс” и взаимодействие с системой (язык, если хотите) можно построить на основе этого “интерфейса”, то есть, одинаково работать и с тем и с другим.
То, что можно использовать наработки из одной системы в другой. Например, в SQL-системах имеются прекрасные оптимизаторы запросов и ещё куча всяческих полезных алгоритмов – вероятно, их можно будет применить в coSQL.
То, что, в конце концов, системы являются трансформируемыми друг в друга (и это следует напрямую из математики).

P.S. Нашел совершенно случайно. Подписался ;)

оно вообще неплохо. работает. только вот мне как-то кажется, что компилить C# в AST, AST в SQL, SQL в query, query в план запроса (см. серию постов zabivator про устройство БД) - это какой-то оверкилл. просадка перформанса в дебаге оч существенная, по крайней мере.

предметная область обычно лучше мапится на динамическое ОО (спорно, конечно, но что делать, если например взяли и ввели проездные билеты на кол-во поездок, в дополнение к проездным на определенный срок)

так вот, кажется, что идеальное API для БД и для работы с файлами – это что-то вроде коллекций, которые хранятся или в памяти, или на носителе, и имеет copy-by-reference (для RAM или private storage) или copy-by-value (для сьемных носителей) семантику. ну и индексами они могут заведовать, чего уж там, это полезно :)

что-то подобное, кажется, приветствуют ребята из Фантома (dz и т.д.)

UPD: ну, не все так радужно, судя по совместному с ev_genus экспириенсу, подводных камней там тонны :) в основном потому, что если выбросить из головы процессы, файлы и потоки, то надо всё заново придумывать. как говорится, техника безопасности написана кровью.