lextasy -> "Re[3]: Языки запросов в объектно-ориентированных СУБД" :

hrg>> Фаулер. Шаблон Single Table Inheritence. Не всегда самый лучший.
hrg>> Основные проблемы возникают, когда разные классы поддерживают один
hrg>> интерфейс и при доставании данных нужно выбрать правильный

l> Ну и выбросить нафиг надо такой интерфейс, для ипользования которого
l> нужно знать, каким именно классом он реализован.
l> И вообще, я про наследование ничего не говорил, не так ли? А если нет
l> никакого наследования, то и Single Table Inheritence тут ни к селу,
l> ни к городу.

Ну уговорил Но одна таблица — один класс подходит только для простейших
случаев

hrg>> Фаулер. Service Layer.
l> Читаем у Фаулера: "Слой служб определяет границы приложения и
l> множество операций, предоставляемых им для интерфейсных клиентских
l> слоев кода. Он инкапсулирует бизнес-логику приложения, управляет
l> транзакциями и координирует реакции на действия."
l> По моему, речь не шла об изоляции объектной БД при помощи
l> какого-то промежуточного слоя. Речь шла о внедрении в ООБД языка
l> реляционных запросов, как метода выборки множеств объектов,
l> удовлетворяющих заданным критериям.

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

hrg>> Зачем? imho достаточно грамотно спроектированной библиотеки.
l> Мне пока тоже достаточно. Но если люди интересуются вопросом, значит
l> это им все-таки нужно. Да и службу коммерции в CORBA неспроста,
l> наверное, ввели...

Хз.. с CORBA не работал. Но наверное не зря

l> PS.
l> Касательно Фаулера. Странно как-то на него ссылаться, когда речь идет
l> об ООСУБД. Он вроде эту тему затронул только один раз — дескать,
l> бывают такие маньяки, которые их используют, но я, дескать, к ним не
l> отношусь.

Тем не менее — он показад проблемы и подходы к их решению. Тема ООСУБД очень
интересная.

Yury Kopyl aka hrg | http://id.totem.ru | Гордость мешает доходам!