Re[11]: Взаимодействие с Базой Данных из C# по схеме MS
От: IB Австрия http://rsdn.ru
Дата: 21.09.08 18:12
Оценка: 227 (13) +5
Здравствуйте, Cyberax, Вы писали:

C> Нет никаких фундаментальных причин по которым OODB не могут соперничать с RDB.

Есть. Фундаментальная причина заключается ровно в том, что OODB жестко привязывает поведение и структуру к данным, а срок жизни данных сильно больше навязанного им поведения, и за их время жизни интерпретация меняется по многу раз. Так что привязывать какое-то конкретное поведение к данным — дурная затея. Во-первых, меняя в десятый раз поведение данные нужно оставлять неизменными. Во-вторых, добавляя новое поведение, надо его просто добавлять, а не менять старое и на накручивать поверх старого, при этом данные должны быть по прежнему неизменными. Ровно эта же причина является и фатальным недостатком классических ORM, там это просто меньше чувствуется, так как данные все-таки реально отделены и лежат в базе, и ничто не мешает навернуть еще одну модель сверху, после того как старая перестала устраивать, но это все равно конкретный косяк, который их рано или поздно похоронит.
Ну возьми реальное приложение, которое работает с данными, на кой байт тебе там полноценный граф объектов? У такой модели хорошо получается только добираться до одного элемента по индексу, но на самом-то деле нужно фильтровать, объеденять, сортировать, агрегировать, причем самым произвольным образом, а на всех этих операциях ОО сосет как промышленный пылесос, по сравнению с моделью старика Кодда. В плоть до того, что для решения таких задач в насквозь объектный C# вкрячили функциональный LINQ, так похожий на SQL, что с двух шагов не отличить.
Мало кому интересен просто список товаров, интересен этот список отфильтрованный и отсортированный по самым причудливым критериям, например по принадлежности к конкретному заказу... Но самое забавное, что заказ и список элементов заказа, практически ни в одном юзкейсе не нужны одновременно, так какого байта в объекте Order делает коллекция OrderItems, потому что "объектно"?
Такая объектность может далеко завести, к примеру, работает у нас сейлз в B2B магазине, для него вполне возможен такой граф объектов Region->Customer->Orders->OrderItems->Product->Vendor... ->Region, упс, граф-то цикличный... Хуже другое, после сейлза пришел вендор-менеджер, а ему от кастомера плясать не интересно, ему граф-то нужен ровно обратный Vendor->Products->OrderItems->Order->Customer. И это мы еще на какого-нибудь логистика не посмотрели, у которого регионы и счета кастомера начинаются прямо от OrderItems и конкретный заказ ему не интересен ему важны все OrderItems до четырех часов сегодняшнего дня, чтобы доставку на завтра спланировать по всем адресам.
В OODB и в ORM-ном графе объектов, еще на этапе проектирования приложения нужно не просто обозначить ничего не обязывающую связь один ко многим, между заказом и продуктами в него входящими, а явно сказать, что коллекция объектов OrderItems принадлежит объекту Order, хотя в 99% юзкейсов не понадобится подгружать Order и OrderItems одновременно и, максимум в 50% юзкейсов, это утверждение о принадлежности вообще имеет смысл, так как отбирать эти OrderItems надо совсем по другому критерию.
Безусловно, это все решаемые проблемы, можно заранее протоптать все пути, можно применить LazyLoading, чтобы подгружать только нужную часть объектов. Закрыть глаза, на то что нигде не контролируется, что подгружается только нужная часть. Прикрутить навороченый двухуровневый кеш, с хитрым механизмом контроля когерентности, чтобы победить стоимость поднятия объекта при навигационном доступе. Использовать, при необходимости, DTO, так как нельзя просто передать объект куда хочется ввиду наличия LL, который уволочет на ту сторону всю базу... И так далее в том же духе, дедка за репку, одно тянет другое, хотя в итоге получается в принципе рабочее решение, которым правда не очень удобно пользоваться, так как пути жестко протоптаны — ну что тут поделаешь зато объектно....
И весь этот зоопарк костылей нужен вместо того, чтобы просто сказать базе — "дай мне пожалуйста всех вендоров, продукты которых мы продали в таких-то регионах, на сумму больше Z у. е." и получить от нее ровно ту информацию, которая нужна (к слову, в виде объекта), а не полный граф от вендора до кастомера.
Возникает только один вопрос — задлянафига нужен этот граф объектов в OODB?!
http://www.rsdn.org/File/343/537.gif Мы уже победили, просто это еще не так заметно...
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.