Хранение объектов не в БД

При проектировании веб-систем более-менее неигрушечного размера (форум, баг-тракинг, wiki) обычно принято хранить данные в какой-нибудь серверной БД.

При разработке TaCo я решил отойти от этого решения. И вот почему...

Impedance mismatch

Или точнее "Object-relational impedance mismatch" - это понятие, которое описывает тот факт, что объектно-ориентированное моделирование и реляционное моделирование построены на разных принципах, и когда их приходится совмещать, это не всегда происходит гладко. Я как-то не смог найти в сети внятного и точного технического описания проблемы, но самая вменяемая, на мой взгляд, статья есть на Wikipedia.

Тем не менее, я, как человек привыкший работать именно с объектно-ориентированным подходом, и являющийся большим его поклонником, частенько на это самое "несовпадение" наталкиваюсь. Среди прочего, меня всем этом вопросе беспокоят следующие аспекты.

Наследование

Теория, что объектная, что баз данных, говорит о том, что логические объекты предметной области следует делать объектами или таблицами соответственно (это я упрощенно). Однако дальше начинаются неприятные различия: объекты могут наследоваться, и им свойственнен полиморфизм. Таблицы же - это плоские образования. Сплошь и рядом в объектной программе можно иметь контейнеры разных наследников одного базового объекта, но хранить в одной таблице записи с разным количеством полей нельзя. Все это можно обойти в БД, но эти способы обычно довольно кривы, и с ними сложно работать.

Инкапсуляция данных

Объект должен иметь все данные, с которыми работает, что называется "при себе". Причем, независимо от их структуры. Наример, если в программе как-то представляется ветка форума, то все ее сообщения будут храниться в ней. В базах данных же данные группируются не по логическому отношению, а по типам: все сообщения одной ветки форума могут быть как угодно размазаны в табличке с сообщениями из всех веток.

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

Избыточное обеспечение целостности

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

Но дальше появляется интересный момент: хорошая объектная программа заботится о корректном состоянии своих объектов сама, а не полагается на ошибки БД (через минуту к тому еще вернусь).

Другими словами, поддержку корректности данных в таких программах часто приходится делать два раза: на уровне БД и на уровне приложения.

Разные способы поддержки корректности

Итак, почему бы объектной программе не полагаться на БД для проверки корректности данных.

Первая причина очень простая: обращение за каждой пустяковой проверкой корректности данных в базу - это неимоверный удар по производительности.

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

На практике эти два подхода стыкуются плохо. Приведу для иллюстрации очень частный пример из недавнего прошлого.

Представим, что нам нужно отслеживать возврат клиентами товаров в интернет-магазин. Нужно знать, когда какие товары принесли и на каких складах они лежат. Для этого есть такие объекты:

• "Возврат товара" - он означает некий факт того, что в магазин обратился клиент с желанием вернуть товар. Этот Возврат может быть в разных состояниях: "Оформлен", "Принят у клиента", "Передан на экспертизу"...

• "Товар" - у Возврата есть список связанных с ним Товаров, так как клиент может за один раз принести их несколько.

В БД эти объекты лежат в виде двух табличек, и табличка Товаров ссылается на табличку Возвратов через внешний ключ - стандартное решение.

Есть разные правила сосуществования всех этих объектов и одно из них для примера: чтобы Возврат можно было перевести в состояние "Принят у клиента", у каждого Товара должно быть проставлено, на какой склад он принят.

Программа дает свободно редактировать и состояния Возврата и Товары пользователю, и дает кнопку, по которой сохраняет изменения в базу, просто вызывая сохранения двух табличек:

Procedure TReturn.Save;
Begin
  GoodsTable.Save;
  ReturnTable.Save;
End;

Эти две строчки по сути просто вызывают соответствующие SQLные UPDATE'ы для таблички Товаров и таблички Возвратов. Заметьте порядок сохранения: сначала сохраняются зависимая табличка, чтобы при сохранении таблички Возврата БД могла проверить, что у всех Товаров действительно проставлена ссылка на склад.

Все, вроде, просто? А теперь представим, что наш Возврат только что создан в программе, и в базе его еще нет. При попытке сохранить табличку зависимых Товаров БД тут же ругнется, что она не может вставлять зависимые записи Товаров, поскольку не существует главной для них записи Возврата - нарушается ссылочная целостность. И вот приходится писать совершенно дурацкую вилку, что "If запись новая Then сохранять в другом порядке". И следить уже за думя кусками кода, если понадобится добавить сохранение еще какой-нибудь таблички.

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

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

Пути решения

Мне известно, по большому счету, два способа разрешать это "несовпадение импеданса".

Первый - это ORM - Object-Relational Mapping. К программе подключается некая библиотека или даже платформа, которая прозрачно для объектного программиста переводит его объекты в модель данных в базе. Проверяет типы, целостность и т.д. Таким образом она решает проблему дублирования: модель данных и доступ к ней определяются один раз в программе, а БД строится по ней автоматически и внимания не требует.

Но платой за универсальность обычно является эффективность: библиотека понятия не имеет, что лучше для логики именно вашего приложения, она действует именно универсальными методами.

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

TaCo

В TaCo я выбрал как раз второй подход. Поскольку система простая и компактная, особенно много думать над сохранением объектов не приходится: они сохраняются в XML-файлы, с которыми в Python'е работать - одно удовольствие.

Немного о том, в какие плюсы и минусы это выливается по ходу разработки:

Плюсы:

• Я могу строить всякие странные хитрые индексы типа списка задач, упорядоченного по времени их последнего изменения, при этом у них нет даже никакого отдельного поля для этого.
• У меня никогда не будет болеть голова про SQL injection.

Минусы:

• Придется писать собственную обработку одновременного доступа к файлам из разных процессов, БД бы сделала это сама.

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