IT-redneck

Коллеги, быть может это мой баг, может я где-то что-то не так описал, но ни Эрик, ни, тем более, я не имели в виду ничего подобного на панацею от всех бед. Уж точно не было ничего похожего на "Выкиньте ваши RDBMS к чертям" :)
Просто... RDBMS не безгрешен. Не беспроблемен, хоть мы к нему и привыкли, считая его безальтернативным по умолчанию. Научившись думать как он.
Есть там много проблем, для которых существуют костылики-решения, обходные пути, либо прямые, но сложные пути.
До Сиднея из Роттердама можно доплыть на судне. И люди так делали. Ничего зазорного. Просто надо запастить временем, провиантом, медикаментами на долгое плавание, взять врача с собой, книжек почитать и т.д. А можно полететь на самолёте. Я летел. Это удобнее! Но лететь из Роттердама в Антверпен - неудобно. Слишком близко. Лучше плыть. Ещё лучше - ехать на машине. Но не в случае, если у Вас тонна-полтора-три-пять-пятьдесят груза. Тогда всё же удобнее плыть.
Инструменты бывают разные, понимаете? Для разных задач. Да, существует большой класс задач, где RDBMS - то, что надо, а ODBMS - не пришей кобыле хвост.
Однако, существуют задачи и обратные. И их больше, чем вам кажется, на самом деле. И, может быть, ваши задачи - из того же класса. Просто мы так привыкли - если база, то взять RDBMS и начать запихивать туда маловпихуемое, распределять, нормализовывать, собирать обратно, ORMить... Хотя может быть ГОРАЗДО проще решить задачу с использованием какого-нибудь MongoDB.
У нас объект "книга" и мы работаем с книгами. В Domain Model, в бизнес-логике мы работаем с книгами. Так на кой же хрен мы рассуждаем о сферических конях в вакууме типа "а ведь могут быть авторы без книг". Бывают ли коты без улыбок? А улыбки без котов? :) Стоп, господа! Мы котами занимаемся! :) Улыбаются - классно, не улыбаются - Кот.Развеселить(); :)
Это наша бизнес-модель, мы с ней работаем, это удобно! В паттерны всякие типа MVC/MVP/MVVM вписывается замечательно, опять же.

О, простой пример. Есть некий сайт, который на страничках отображает некую информацию о неких объектах. О людях, скажем. "Человек" - это бизнес-объект. Он сложный, там и адреса, и телефоны, и линки, и интересы, и имейлы, и чего только нет.

Один подход: нормализовать человека, распихать в таблицы адресов (+справочник "тип адреса"), телефонов (+справочник "тип телефона"), линков (+справочник "тип линка") и т.д. и т.п. Вы лучше меня знаете, посмотрите в свои проекты.

Другой подход: создать тип (класс) "пользователь" в любимом языке программирования и работать с ним. Положил объект "пользователь" в базу, вынул объект "пользователь" из базы. Две операции, никаких джойнов, маппингов, ORM-систем, определений "вот щас пользователь обновил вот этот телефон, поэтому мы делаем update в такую-то таблицу", никаких foreign keys, кластерных-некластерных индексов по ним, оптимизации SQL (вообще нет SQL), ругани с DBA по поводу того, что Hibernate сгенерил SQL, который ему не нравится (вообще нет SQL!), etc, etc.
Просто "база, дай мне человека" и "база, сохрани человека, я тут его поправил...".
Плюс версионность for free (а пойдите-ка сделайте версионность на RDBMS, чтобы можно было глядеть, каким был наш человек три изменения назад? со всеми адресами, телефонами и прочим, конечно), плюс scalability for free и без выкрутасов, плюс ещё что-нибудь - разные DB дают разные функциональности.

Понятное дело, что что-то дают, а чего-то лишают, а для чего-то тоже есть обходные пути и костылики :) Тоже разные аспекты, но мы можем выбрать не из одного типа инструмента, между "гвоздодёр Bosh или гвоздодёр Simens", а между "гвоздодёр и отвёртка", понимаете?

А самое главное - мы концентрируемся на бизнес-логике нашего приложения. На том, что именно оно должно делать с человеком. ЧТО ОНО ДЕЛАЕТ, а не КАК ХРАНИТЬ. Мы больше не пляшем от схемы базы данных. Случалось вам так делать? Сначала схема - потом логика. Хотя по уму-то, мир в обратном порядке работает, согласитесь.
Если нам понадобился тип Суперчеловек, мы просто делаем потомка класса, добавляем кучу новых свойств, поведений и нашу бизнес-логику - и всё продолжает работать. Базе всё равно, какого человека сохранять, там все равны, там коммунизм.
Это ли не класс задач, которых очень много и которые отлично решаются данным подходом? :)