Доклад Эрика Майера о noSQL был лучшим на YOW!2010, по крайней мере из тех, что я видел. Уровень исполнения – выше всяких похвал. Одако, отдельно отметить его я хотел именно из-за его содержания.
Итак, краткая стенограмма.

Вначале Эрик сказал, что не так давно проходила конференция, посвящённая noSQL-системам, где был выдвинут важный тезис: мы знаем, что такое SQL, но мы до сих пор не знаем, что такое noSQL, поэтому мы бродим в потьмах и не знаем, что делать.
- Теперь у меня есть на это ответ. Я знаю, что такое noSQL и покажу вам. Больше нет никакого смысла противопоставлять SQL и noSQL, теперь наступит мир, сказал Эрик.

Для иллюстрации проблем, связанных с реляционными базами данных, он привёл простой пример:

public class Book {
    public string Title {get; set; }
    public IEnumerable<int> Ratings {get; set; }
    public IEnumerable<string> Authors {get; set; }
}

Итак, мы имеем объект, содержащий коллекции каких-то других объектов. Тут важно вспомнить, что слово “содержащий” фактически означает различный набор ссылок, то есть, фактически, Book ссылается на объекты рейтингов и авторов. Такой вот небольшой понятный граф, который мы хотим сохранить в БД.

Здесь начинаются “проблемы”, так как таблицы реляционных БД, могут хранить только скалярные значения. Иначе говоря, если описать в некой семантической форме, то значение в реляционной БД хранится в виде:

value = {scalar * scalar * scalar … } //так есть

и не может быть сохранено в, например, виде:

value = {scalar * value * scalar … } //а так – нету.

Эрик отметил здесь, что одна из главных проблем тут – отсутствие возможности композиции, отдельно сделав упор на то, что отсутствие рекурсии в вышеуказанной семантике и приводит к подобным проблемам.

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

Наиболее эмоциональной частью выступления стала часть, посвящённая нормализации.
Эрик показал, что для сохранения экземпляра вышеуказанного типа Book необходимо провести нормализацию. То есть, в БД мы имеем для этого три таблицы: Books, Ratings и Authors (я не стану их рисовать, это легко представить). Каждая из этих таблиц имеет первичный ключ (некий ID). Две из этих таблиц имеют ссылки на первичный ключ первой (Foreign Keys).
Таким образом, заявил Эрик, из моего простого объекта получилось вдруг три новых, в которые добавились какие-то новые сущности (идентификаторы), не имеющие к реальному объекту никакого отношения, плюс нужно писать дополнительный код, осуществляющий трансформацию. “Нормализация?! – возмущался Эрик – Почему этот термин назван нормализация?! Вы правда считаете это нормальным, так делать?!”

Посмотрим дальше на запросы к данным. Для того, чтобы получить список книжек с высоким рейтингом из коллекции Books, потребовался бы достаточно простой запрос, тогда как в случае “нормализованного” хранилища уже ридётся использовать join’ы, что приведёт к серьёзному усложнению решения простой задачи.

Ещё много всяких “косяков” связанных с самой идеей SQL и реляционных БД приводил Эрик, однако я перейду к сути “проблемной” части, почти словами Эрика:

1. Я создаю мой прекрасный тип Book. Он простой, понятный и с ним легко работать.
2. Приходит другой человек и “портит” мой тип, создавая вместо него три других, пихая туда всякие неотносящиеся к делу IDs и т.д.
3. Приходит БД-человек, и начинает решать обратную задачу, как-бы воссоздавая из всего этого “нормализованного” вида то, что у меня уже и так было в самом начале!

На пункте #3 становимся чуть подробнее. Все эти join’ы и IDs – они служат только для того, чтобы поддерживать целостность некого логического объекта Book. Сервер БД внутри себя содержит алгоритмы немереной сложности для поддержки целостности данных с помощью foreing key – только для того, чтобы обеспечить целостность объекта Book. Индексы. Что делают индексы? Фактически, это пре-подготовленные справочники того, как одни таблицы связаны с другими, то есть, опять же, служащие для того, чтобы быстро иметь возможность понять, какая запись в таблице Ratings “принадлежит” какой записи в таблице Books.
То есть, все эти умные механизмы служат одной и той же цели: восстановить то, что я имел в пункте #1 после того, как это было испорчено в пункте #2.

Ну а теперь непосредственно к делу

- Меня на курсе математики научили только одной вещи, я в жизни знаю только один трюк. Это трюк – двойственность, пошутил Эрик.

Если обратить внимание на то, чем отличаются две эти модели друг от друга, то можно заметить самое главное: в исходном “ссылочном” подходе “родитель” так или иначе “знает” о своих потомках (имеет на них  ссылки). В результирующем “реляционном” подходе наоборот - потомок всегда знает о том, кто его родитель. Вот здесь Эрик и заприметил возможность применить свой любимый трюк.
То есть, чтобы получить одно из другого, нужно всего лишь, выражаясь его языком, “развернуть стрелочки”!

- Наша отрасль называется “computer science”. Вы заметили, что все “настоящие” науки не имеют слова “science” в своём названии? Химия, физика, математика… Поэтому когда в нашем “science” возникает проблема, я знаю, что скорее всего она уже решена в “настоящей” науке и пришло время обратиться к математике. Я открыл гугл и набрал слова “математика развернуть стрелочки”. Ба! Википедия! Теория категорий и ко-алгебра! Теперь я точно знаю, что есть решение проблемы!

Так Эрик описал процесс

Ну а дальше они засели, как он выразился, с “настоящими математиками”, чтобы доказать действительность двойственности SQL и noSQL. И у них это получилось. И теперь Эрик предлагает называть это не noSQL, а coSQL, в соответствии с математическими стандартами, как co-alghebra.

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

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

На мой взгляд – очень стоящее открытие. Публика тоже была в восторге.