Подробнее о табличных базах данных

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

Однако доминирующий системой хранения данных для бизнес-приложений является табличная (реляционная) база данных. Эта модель реализована, например, в таком типе хранилища данных как SQL сервер.

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

Первый подход - когда объекты, которыми оперируют программисты - это таблицы. И, соответственно, все бизнес-приложения строятся как приложения, которые работают с таблицами.

В данном случае ключевой проблемой в реализации приложения является необходимость до начала написания кода сформировать комплексную модель бизнеса (подсистемы бизнеса), которая будет реализована в бизнес-приложении.  А далее делается декомпозиция данной модели до модели таблиц. Для чего это необходимо?  Дело в том, что для достижения приемлемой производительности при использовании табличной системы хранения данных создание набора таблиц, которые будут использоваться при работе бизнес-приложения, требуется выполнять определенные правила. И эти правила оптимально работают, когда сразу описывается вся будущая система.

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

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

Сколько мы знаем примеров неудачных внедрений бизнес-приложений из за простой проблемы. К моменту, когда система наконец написана (настроена) программистами - требования к системе поменялись, и она не может быть использована в полном объеме.

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

Второй подход - когда используются "квазиобъектные" механизмы хранения данных (постреляционная база данных). То есть на уровне программирования используются объекты, а хранится информация в табличной базе данных. Такая система реализована, например, в 1C7, 1C8, Microsoft CRM  и многих других современных системах.

Такой подход автоматически порождает множество проблем.

Каждый раз при чтении или сохранении объекта требуется "конвертировать" данные из табличных в объектные и наоборот. Это поглощает ресурсы компьютера, и требует приобретения компьютеров высокой производительности для внедрения самых простых бизнес-приложений (вспомним проблемы производительности хотя бы, например, 1С8).

Попытка представить даже простые объекты в виде таблиц привозит к созданию очень сложных табличных моделей данных. К чему это приводит:

  • На выполнение сложных запросов SQL сервер тратит много ресурсов, как следствие - все те же проблемы с производительностью компьютеров.
  • Невозможно создавать сложные объекты. Как правило набор классов объектов, которыми можно оперировать в таких системах ограничен, либо их сложно расширять.

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

Объектная СУБД ODA™  полностью лишена этого "генетического" недостатка квазиобъектных систем, так как использует в работе объектную базу данных.  Получение и сохранение данных производится в объектном виде. Не происходит конвертации данных. В результате:

  • Нет потери производительности
  • Нет ограничений по сложности объектов