Здравствуйте, GlebZ, Вы писали:

AVK>>Ты когда нибудь видел в SQL-серверах возможность править результат select?
GZ>Вьюхи instead of.
Не понял, и что смешного. Я сначало писал про update, тут спросили про select. Ну и ошибся. Правильный ответ функции в Oracle(как работают функции в MSSQL не знаю. Утверждать не буду, но возможно тоже).

Здравствуйте, Дарней, Вы писали:

IT>>Во-вторых, я могу иметь распределённую систему и не иметь при этом хранилищ на разных узлах.

Д>интересно, каким тогда образом?

Есть такая штука — база данных.

Здравствуйте, Adopt, Вы писали:

A>Что такое таблица с B+ индексом?
Имелась ввиду таблица с индексом на основе B+ tree.

Здравствуйте, Дарней, Вы писали:

Д>Динамическая типизация это тоже не панацея
Ну, а что же ты тогда о ней заикался?

Д> Осталось только выяснить, что в ней плохо и нуждается в улучшении.
Выясняют уже больше пятнадцати лет. Успехов.

Д>А если не устраивают оба варианта, что ты предлагаешь делать?
Брать тот, где проблем меньше — опять проблемы с чтением?

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

M>>По кругу поехали?
Д>ага.
Тогда без меня.

Д> А кто сказал, что обработка новых записей по старым правилам — допустима?
Ну так не обрабатывай.

Д>К каким данным вот здесь у тебя нет доступа?
Ко всем.

Д>Менять код.
В сад.

Д>А в чем проблема то?
В том, чтобы делать методы на всякий случай.

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

Д>Уже сравнил. Реляционки за 1985 год совсем не порадовали меня своими фичами.
Опять не внимательно читаешь...

Д> Так что адью.
Сломался...

Здравствуйте, Sinclair, Вы писали:

GZ>>А может стоит тут интерпретировать не как объекты OODB, а именно как объекты из компоненты OODB?
S>Че-то не улавливаю. Ты не мог бы развернуть?
Легко сказать да трудно сделать. Страдаю глобализмом. Все нижеследуещее следует считать во первых IMHO, во вторых относящимся именно к объектно-ориентированным базам а никак иначе. Вопросы навигации не рассматриваю.
Итак. Прежде всего некоторые тезисы. Тезисы по поводу РСУБД, касаются именно именно идеальной реляционки времен Кодда и SystemR. Кое что было решенов рамках СУБД, кое что с помощью сервисов поставляемые с той, или иной базой данных.
1. Недостаток РСУБД. Скудность информации данных. Зачастую о смысле данных можно узнать только перерыв приложение которое его использует.
2. Недостаток РСУБД. Недостаточная эффективность реляционной модели. Вряд ли что эффективней работает на строгоструктурированными данными чем РСУБД, но так как мы имеем данные огромного объема даже этого механизма не хватает. В ответ на это появились вычислимые поля на триггерах, материализованные вьюхи, временные таблицы и прочая лабуда.
3. Недостаток РСУБД. Даже для задачи хранения и получения данных, нужны вычисления. А для вычислений нужен язык. В РСУБД были внедрены языки, но поскольку первичная их задача — доступ к данным. На вычислительную мощность, и, в большей степени, на удобство пользования разработчики положили.
4. Недостаток РСУБД. Недостаточность инкапсуляции. Вьюхи в классическом виде не выполняют своей роли полностью так как работают на чтение. На данный момент можно пользовать stored procedure, которую нельзя включить в custom SQL запрос. Или с помощью триггеров instead of навешанную на VIEW или Table. Еще в некоторых базах существуют функции(сразу признаюсь что не знаю, используются они в оптимизации запросов, или нет).
5. Недостаток OOСУБД. Инкапсуляция. Инкапсуляция хороша от внешних злодеев, и очень вредна внутри OOСУБД. Наибольший пострадавший в данном случае — оптимизатор запросов.
6. Недостаток OOСУБД. Слишком сильная привязанность к таблицам и месту хранения. Во многом это усуглубляет недостаток РСУБД из пункта 2 полученный в наследство. Даже скажу, очень сильно усуглубляет.
7. Недостаток OOСУБД. Объект который имеет состояние, и управляет им тяжел и неудобен в сопровождении. После того, как я перестал использовать в бизнес-объектах функционал реализующий работу с их состоянием, чессно-слово, обрел нирвану. Поэтому желательно разделение бизнес-объекта и бизнес-сервиса. Таким образом это улучшает сопровождаемость кода.
8. Принцип Деметры(принцип хорошего проектирования):

Для любого класса C и для любого метода M, связанного с C, все объекты, которым M посылает сообщение, должны быть экземплярами классов, ассоциированными со следующими классами: классами аргументов M (включая C); классами переменных экземпляра C.

Взято отсюда.здесь. Интересная статья, советую прочитать.
9. Предыдущий пункт сильно противоречит ad-hoc запросам в РСУБД в которых ты можешь взять любую таблицу, и сджоинить с любой другой таблицей. Правда при этом надо учитывать фактор индексов, без которых данная операция будет безбожно тормозить.
9. Все что можно уже выдумано до нас. В частности компонентность и модификаторы компонентности.
10. Все что можно уже выдумано до нас. В частности версионификация. Объекты легко адаптируют в компонентной программе сразу для нескольких клиентов.
11. SQL хотя не является процедурным языком, но также не является и функциональным, так как не поддерживает рекурсию. Соответсвенно на нем нельзя строить произвольно сложные запросы.
12. Недостаток OODB. Он пытается увеличить скорость навигационных запросов путем адаптации хранилища к ним. Он сознательно адаптирует хранилище под конкретное приложение согласно объектной схеме. (Это я намекаю на хранение подчиненных коллекций и объектов вместе с объектом владельцем). Соответвенно теряется эффективность ad-hoc запросов.
12. Для оптимизатора запросов важна подробная информация.


Итак вооружившись этими тезисами, начинаю сочинять(играю как умею, в пианиста не стрелять).
Для каждого вида бизнес-объектов строится пара — объект состояния(хранящий состояние), и объект доступа(выполняющий операции связанные с данным объектом состояния).
Объект состояния.
1. Он только предоставляет интерфейс доступа к состоянию. Реализация доступна только в самой сборке.
2. Объект зависит от заказываемой версии. То есть, одна и та же таблица или результат может быть инстанцирована несколькими объектами в зависимости от заказываемой версии.
3. Таблица всегда содержит объекты последней версии. Объект может быть не инстанцирован никогда, и его задача только в описании метаданных для таблицы.
4. Объект содержащий данные может быть не виден за пределами сервера OODB, и использоваться только внутри ее.
5. Объект состояния может быть не привязан к таблице, и использоваться только для сборки внутри сервера, и отправки состояния клиенту.(для аналога view)
6. Объект в силу пункта 2(версионификация), может быть собран через кодогенерацию(для метапрограммирования мешает режим 24x7).
7. Объект должен быть настолько прост, насколько он может показывать свое состояние, и содержать элементарные бизнес-правила(аналог check).

Объект доступа.
1. Основная его задача не получить или изменить объект. Основная его задача указать менеджеру запросов как преобразовать запрос для использования данного типа объектов.
2. Объект может передавать управления другим объектам доступа(для реализации аналога view).
3. Объект должен поддерживать инстанцирование и разбор объектов всех версий.
4. Объект должен поддерживать версионификацию по комовскому типу. Например, показывать только свой интерфейс, который в свою очередь зависит от заказываемой версии запроса. И обрабатывать запрос в свою очередь согласно заказанной версии.
5. Все методы объекта должны быть функциональными. Это важно для оптимизатора запросов. На входе граф запроса и контекст выполнения, на выходе трансформированный граф запроса и контекст.
6. Методы получения объектов состояния и записи состояния могут быть сильно различными. Ну например, для автоматической поддержки аггрегируемых значений.
7. Существуют методы частичного вычисления. То есть, вместо того, чтобы выстраивать полный запрос, перенаправлять на таблицы которые уже содержат часть результатов.
8. В связи с предыдущим пунктом можно увеличить производительность, строя кэш результатов на те или иные объекты состояния(аналог материализованных вьюх, только в контексте OODB).
9. В связи с предыдущим пунктом можно даже увеличить производительность за счет поддержки индексирования значений методов.(точнее не даже, кое-кто такое поддерживает).

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

Может я в чем-то ошибаюсь, все это IMHO, но это мое виденье хорошей OODB.

Здравствуйте, Merle, Вы писали:

M>Здравствуйте, shuklin, Вы писали:

S>> Какие здесь подводные камни?
M>Основной подводный камень — сделать все на основе ООБД. В самом понятии ООБД содержится некая ущербность. Дело в том, что ОО — это не голые данные, а прежде всего поведение. Иными словами ОО это некоторая обертка над данными, которая навязывает этим данным определенное поведение.

M>Из вышеказанного следует, что для систем с высокой степенью изменчивости и большим количеством разнородных данных, к которым относится и ОС, ООБД в чистом виде — не подходят.

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

Я тоже думаю, что ООБД не заменят РБД. Кстати, пора бы уточнить понятия. Тут уже начали говорить про активность объектов. Я то понимал под ООБД просто другую модель данных. Вместо плоской- иерархическую-сетевую с наследованием. Язык запросов какой-то отличный от SQL. А не то что объекты обязательно выполняются.

За РБД стоит теория. Интересно, что стоит за ООБД? Какие там языки запросов?

Кстати, для расширения кругозора: было предпринято много попыток прикрутить Пролог к РБД. Даже был такой европейский исследовательский проект по созданию реляционного ЯБД Дейталог, основанный на синтаксисе и идеях Пролога. У меня есть книжка. Так вот скажу, что в ней много разных теоретических математических подходов. Идея превосходная, но окончательной реализации вроде небыло предложено. Незнаю как сейчас, но что-то не слышно даже про Пролог. Боюсь что за терминами типа ООП, ООБД ничего не стоит кроме голой практики и более-менее сложные вещи сведут на нет все преимущества ООБД. Кстати, любопытно сравнить сложность реализации ООП в С++ и механизма вывода в Прологе. Последняя технология гораздо труднее для реализации и понимания. Я говорю только о сложности. Кажется ООП расширения Пролога тоже есть.

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

Вобщем, назовите задачи, которые требуют ООБД.

Здравствуйте, Merle, Вы писали:

M>Сломался...

я вообще не любитель теологических диспутов...

Здравствуйте, IT, Вы писали:

IT>Есть такая штука — база данных.

и что? Много ты видел больших распределенных систем, которые построены на базе данных?

Здравствуйте, Sinclair, Вы писали:

S>Гм. Там все банально. Для B+tree мы, получив диапазон, очень быстро спускаемся к его левой границе и начинаем последовательное сканирование страниц. Поскольку листья образуют двусвязный список, это очень эффективно.
Да я все это понимаю. Просто в описанных нами элементарных операциях мы не имеем возможности получить диапазон.
S>Именно поэтому хэшиндексы и стали менее популярны — нет поддержки range scan, и нет побочного эффекта упорядоченности ключей.
Зависит от того, что мы имеем ввиду под хеш-индексом. Их достаточно много. Тот что здесь — имеетRe[18]: Настольная БД

Автор: GlebZ
Дата: 05.04.06

. Правда не без побочных эффектов.

Здравствуйте, Дарней, Вы писали:

Д>и что? Много ты видел больших распределенных систем, которые построены на базе данных?

Много, иначе бы не говорил. Практически все проекты в которых я участвовал в последние несколько лет имеют либо кучу серверов приложений, либо (или в том числе) WebFarm и одну или несколько баз данных. Где несколько БД означает хранение разных, зачастую очень слабо или вообще не связанных между собой данных.

А ты много выидел больших распределённых систем, построенных ООП?

Здравствуйте, Дарней, Вы писали:

Д>Здравствуйте, Merle, Вы писали:

M>>Не смотря на то что ООП, как таковое, уже пережило бурный рост и движется к закату

Д>надо же, как интересно. А что, объектов больше не будет?

Ага. Их отменили.

Здравствуйте, GlebZ, Вы писали:


IT>>Интернет — это глобальная распределённая сеть. И глобальная и распределённая, т.е. то о чём ООП может только продолжать мечтать. И заметь, это работает и ни мне ни тебе это не надо доказывать. Мы оба знаем что это так.
GZ>Во первых, отчего же все меньше баз опубликовано в интернете, и все больше SOA? Реляционка как серьезная распределенная база данных — практически неприменима.

Не стоит отождествлять SOA с OO и тем более с ООБД.
Все больше SOA? Похоже речь идет конктртно о веб-службах как о частном случае SOA.
Причина популярности веб-служб:
1) наличие стандартов
2) продвижение этой технологии большими конторами (IBM, HP, MS)
3) наличие огромного количества инструментальных средств для работы с ними (это следствие 2)

Если же отойти от веб-служб и посмотреть на SOA как на концепцию, то понятно, что она к ОО никакого отношения не имеет.

Здравствуйте, dimon0981, Вы писали:

D>Не стоит отождествлять SOA с OO и тем более с ООБД.
А где ты такое видел?
D>Все больше SOA? Похоже речь идет конктртно о веб-службах как о частном случае SOA.
D>Причина популярности веб-служб:
D>1) наличие стандартов
D>2) продвижение этой технологии большими конторами (IBM, HP, MS)
D>3) наличие огромного количества инструментальных средств для работы с ними (это следствие 2)
4. Web-сервисы в большей степени отвечают свойствам компонентности и способны к самоописанию.
Это отнюдь не простой заговор корпораций с во главе W3C (первая версия была от W3C)

Здравствуйте, IT, Вы писали:

IT>Много, иначе бы не говорил. Практически все проекты в которых я участвовал в последние несколько лет имеют либо кучу серверов приложений, либо (или в том числе) WebFarm и одну или несколько баз данных. Где несколько БД означает хранение разных, зачастую очень слабо или вообще не связанных между собой данных.

Web farm — это, по твоему, распределенная система? Это всего лишь система распределения нагрузки. В ней нет ключевых признаков распределенной системы — ненадежность коммуникаций, большая стоимость и долгое время ожидания запроса между узлами, отсутствие синхронизированного времени.
Мягко говоря, это называется подменой условий задачи.

Здравствуйте, Дарней, Вы писали:

Д>Web farm — это, по твоему, распределенная система?

Боюсь, у тебя несколько однобокое понятие о том, что такое распределённая система.

Здравствуйте, IT, Вы писали:

IT>Боюсь, у тебя несколько однобокое понятие о том, что такое распределённая система.

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

Здравствуйте, Дарней, Вы писали:

IT>>Боюсь, у тебя несколько однобокое понятие о том, что такое распределённая система.

Д>скорее, у тебя слишком размытое. Ты просто путаешь распределенку с кластерами, хотя это очень разные вещи. Практически в любой литературе проводится различие между этими двумя вещами...

Причём тут кластер вообще? Или по твоему веб-фарм == кластер?

Здравствуйте, IT, Вы писали:

IT>Причём тут кластер вообще? Или по твоему веб-фарм == кластер?

э.... а мы под кластерами точно одно и то же понимаем?

Здравствуйте, GlebZ, Вы писал
GZ>Легко сказать да трудно сделать. Страдаю глобализмом.

GZ>Итак. Прежде всего некоторые тезисы. Тезисы по поводу РСУБД, касаются именно именно идеальной реляционки времен Кодда и SystemR. Кое что было решенов рамках СУБД, кое что с помощью сервисов поставляемые с той, или иной базой данных.
GZ>1. Недостаток РСУБД. Скудность информации данных. Зачастую о смысле данных можно узнать только перерыв приложение которое его использует.
Хм. Не очень ясно, что же ты имеешь в виду. Я попробую развернуть здесь эту критику поподробнее:
— отсутствие внятной концепции метаданных. Классический SQL вообще не содержал средств работы с метаданными. Клиентское приложение должно было получить знания о таблицах/view и их колонках эзотерическим путем). Справедливости ради стоит отметить, что в новых версиях стандарта SQL работа с метаданными таки предусмотрена
— малое внимание к связям. FK трактуются как декларативные ограничения, к которым довольно сложно получить доступ, в то время как это на самом деле first-class citizens. Фактически, объявление FK вводит новый тип данных — "ссылка на таблицу", и это должно быть очевидно и легкодоступно.
— 100% отсутствие информации о структуре бинарных объектов. Тут уже точно пошла жесткая необходимость рыться в исходниках клиентского приложения для понимания сути blob.
Работы по поддержке пользовательских типов вместо blob и переносе хотя бы части семантики внутрь БД не слишком скоординированы. Насколько я знаю, попытки стандартизовать UDT есть, но реальная картина в мире СУБД печальна: каждый производитель тянет одеяло на себя. Кстати, стоит отметить полную бесперспективность данного подхода в отстутствие управляемой среды: исполнение пользовательского кода в контексте сервера, который должен обеспечивать высокую надежность — самоубийство.

GZ>2. Недостаток РСУБД. Недостаточная эффективность реляционной модели. Вряд ли что эффективней работает на строгоструктурированными данными чем РСУБД, но так как мы имеем данные огромного объема даже этого механизма не хватает. В ответ на это появились вычислимые поля на триггерах, материализованные вьюхи, временные таблицы и прочая лабуда.
Я бы не был так категоричен. Сама по себе реляционная модель не может обладать никакой эффективностью. Есть средства эффективной реализации некоторых выражений реляционной алгебры. Например, это индексы. Важно понимать, что индексы не являются частью реляционной модели. Опять же важно понимать, что каждый тип индексов приспособлен для оптимизации определенного класса запросов. Популярность B+tree напрямую связана с широтой класса улучшаемых запросов. Тем не менее, B+tree — не панацея. Есть и другие типы индексов, которые могут оказаться уместными в различных ситуациях. В частности, агрегатные индексы, типичные для OLAP-баз, позволяют добиться невероятных результатов. При работе с древовидными данными разработчики как правило реализуют ту или иную схему индексации поверх основной реляционной модели (Селковские диапазоны или транзитивное замыкание).
Материализованное view — это паллиатив, попытка реализовать сразу несколько типов индексов, не встроенных в движок. Временные таблицы — это вообще нонсенс; это попытка обойти либо ограничения выразительности языка, либо ограничения оптимизатора. И если со вторым еще как-то можно смириться — оптимизаторы неуклонно совершенствуются, и нужда явно указывать способ хранения промежуточных результатов снижается, то проблема с первым напрямую связана с убогостью SQL. К этому пункту мы еще вернемся.
GZ>3. Недостаток РСУБД. Даже для задачи хранения и получения данных, нужны вычисления. А для вычислений нужен язык. В РСУБД были внедрены языки, но поскольку первичная их задача — доступ к данным. На вычислительную мощность, и, в большей степени, на удобство пользования разработчики положили.
GZ>4. Недостаток РСУБД. Недостаточность инкапсуляции. Вьюхи в классическом виде не выполняют своей роли полностью так как работают на чтение. На данный момент можно пользовать stored procedure, которую нельзя включить в custom SQL запрос. Или с помощью триггеров instead of навешанную на VIEW или Table. Еще в некоторых базах существуют функции(сразу признаюсь что не знаю, используются они в оптимизации запросов, или нет).
В общем-то да. Жизнь показала, что потребность в запросах в основном сводится к вытаскиванию данных. Опять же, нужно понимать, что стоимость движка напрямую зависит от заявленной функциональности. Я думаю, что нормальная спецификация SQL могла быть разработана еще в начале 80х, но она бы так и лежала на полке из-за проблем с реализацией.
Тем не менее, надо понимать, что фундаментальными проблемами SQL являются:
— отсутствие внятной модели скалярных функций, в том числе и с рекурсивным определением
— отсутствие внятной модели реляционных функций
Стоит отметить, что современные коммерческие RDBMS хоть как-то пытаются решать эти вопросы. Тем не менее, я до сих пор не знаю СУБД, где можно передать внутрь функции ссылку на реляционное выражение. Все, что пока возможно — это построить функцию со скалярными аргументами, которая вернет таблицу. Причем далеко не все производители реализуют такую функциональность с приемлемой эффективностью. Abstraction penalty в некоторых случаях больше похожа на death sentence: например, в Interbase никакой оптимизации табличных функций в принципе не было (на момент версии 5.6, с которой я съел достаточное количество соли, возможно это исправили в новых клонах). В MS SQL разработчику хотя бы дают выстрелить себе в ногу.
Вместо расширения декларативной модели, комитет изобретает частные затычки — например, CTE. О, классно, мы теперь можем делать рекурсивные запросы, ура! Если бы SQL позволял писать table-valued функции с табличными параметрами, мы получили бы то же самое в качестве побочного эффекта. Увы и ах.


GZ>5. Недостаток OOСУБД. Инкапсуляция. Инкапсуляция хороша от внешних злодеев, и очень вредна внутри OOСУБД. Наибольший пострадавший в данном случае — оптимизатор запросов.
Это неверно. Инкапсуляция вовсе не означает криптологию: она фактически запрещает строить код, статически завязанный на подробности реализации, а вовсе не получать информацию о внутреннем устройстве кода. Ну, вот например, допустим компилятор С++ видит в некотором месте вызов метода A::a(). Соответствие областей видимости компилятор проверит первым делом, так что внешний код скомпилируется только если a() public, и т.п. Но сразу после выполнения этой проверки компилятор может забыть все эти модификаторы доступа. Если внутри этого метода всего лишь идет обращение к полю экземпляра, пусть даже и приватному, компилятор имеет полное право устранить вызов путем инлайнинга и выполнять прочие модификации. С точки зрения С++, private прячет интимности от кода, но не от компилятора. С точки зрения управляемой среды, оптимизатор всего лишь имеет права "врача, священника, и мужа" по отношению к коду хранимых сущностей, т.е. соответствующий reflection permission. Это никак не нарушает инкапсуляцию.

GZ>6. Недостаток OOСУБД. Слишком сильная привязанность к таблицам и месту хранения. Во многом это усуглубляет недостаток РСУБД из пункта 2 полученный в наследство. Даже скажу, очень сильно усуглубляет.
Вот это я не очень понимаю. Это же неудачное стечение двух совершенно различных обстоятельств: отстутствие достаточно декларативного языка запросов, и отсутствие оптимизатора, который мог бы воспользоваться избыточной информацией в индексах.

GZ>7. Недостаток OOСУБД. Объект который имеет состояние, и управляет им тяжел и неудобен в сопровождении. После того, как я перестал использовать в бизнес-объектах функционал реализующий работу с их состоянием, чессно-слово, обрел нирвану. Поэтому желательно разделение бизнес-объекта и бизнес-сервиса. Таким образом это улучшает сопровождаемость кода.
Я не уверен, что эта нирвана связана с неудобством прямого управления состоянием. Вообще, конечно же, статическая трактовка данных, принятая в RDBMS, сильно упрощает жизнь. Хотя это вовсе не 100% упрощения, и проблемы с сопровождением все равно есть. В самом оптимистичном случае, когда вносимые изменения не требуют модификации фактологической модели (т.е. мы, к примеру, все еще считаем "телефон" скалярным атрибутом сущности "клиент", а не заменяем это на связь многие-ко-многим), все равно есть риск нарваться на несовместимость логики, когда данные находятся в состоянии, валидном с точки зрения предыдущей модели, но недостижимом в новой модели. Основное упрощение в RDBMS связано с тенденцией консолидировать логику в относительно небольшое количество крупных фрагментов. Однако у этой палки есть и обратная сторона: низкий уровень декомпозиции увеличивает общий объем необходимых изменений. В хорошо спроектированной объектной модели логика состоит из большого количества слабо связанных фрагментов, и все изменения можно четко локализовать.

GZ>8. Принцип Деметры(принцип хорошего проектирования):
GZ>

GZ>Для любого класса C и для любого метода M, связанного с C, все объекты, которым M посылает сообщение, должны быть экземплярами классов, ассоциированными со следующими классами: классами аргументов M (включая C); классами переменных экземпляра C.

GZ>Взято отсюда.здесь. Интересная статья, советую прочитать.
GZ>9. Предыдущий пункт сильно противоречит ad-hoc запросам в РСУБД в которых ты можешь взять любую таблицу, и сджоинить с любой другой таблицей. Правда при этом надо учитывать фактор индексов, без которых данная операция будет безбожно тормозить.
На практике, имхо, 99% джойнов непосредственно связаны с foreign key. Поэтому можно сосредоточиться на оптимизации именно этих запросов, а все остальное трактовать как дополнительные критерии отбора, применяемые к результатам этих нативных операций. Фишка именно в том, что потребность джойнить именно любую таблицу с любой возникает крайне редко. "Адхокность" запросов, я уверен, можно сильно ограничить без особого ущерба для функциональности. Более того, возможно, что наличие подобных ограничений принесет больше пользы, чем вреда, принуждая разработчика к повышению качества проектирования приложений.

GZ>9. Все что можно уже выдумано до нас. В частности компонентность и модификаторы компонентности.
?
GZ>10. Все что можно уже выдумано до нас. В частности версионификация. Объекты легко адаптируют в компонентной программе сразу для нескольких клиентов.
?
GZ>12. Недостаток OODB. Он пытается увеличить скорость навигационных запросов путем адаптации хранилища к ним. Он сознательно адаптирует хранилище под конкретное приложение согласно объектной схеме. (Это я намекаю на хранение подчиненных коллекций и объектов вместе с объектом владельцем). Соответвенно теряется эффективность ad-hoc запросов.
Угу. Я считаю это членоудлинительством: много рекламы и мало практической ценности. Такие ODBMS оптимизируют самую ненужную операцию: инстанцирование комплексных объектов. Вместо этого необходимо уменьшать количество объектов, которые надо инстанцировать в рамках выполнения запроса.
GZ>12. Для оптимизатора запросов важна подробная информация.
Ну, с этим никто не спорит. Вообще здесь, как и много где еще, работает правило Парето: 80% успеха обеспечивается 20% усилий.
В частности, для RDBMS оказывается, что даже минимальной статистики (типа количества уникальных значений ключа индекса) достаточно для выбора планов, близких к оптимальным. Следующий шаг — построение гистограмм распределений — позволяет добиться еще некоторого сокращения лишних операций. Дополнительная семантическая оптимизация на основе данных о констреинтах позволяет улучшить планы в граничных случаях. В принципе, уже этой информации достаточно оптимизатору для того, чтобы почти не оставить шансов человеку на улучшение запросов.
Вменяемый ODBMS оптимизатор должен справляться не хуже. Все, что ему нужно — доступ к телу используемых методов. Все равно в итоге идет обращение к полям экземпляров и классов; поэтому особенной разницы в оптимизациях нет. С одной стороны, все кажется сложным — типичный "объектный" запрос будет иметь значительно более сложное AST, чем типичный реляционный. С другой стороны, есть очень хороший шанс использовать кэш. В частности, если посмотреть на статистику Jit для Януса, то окажется, что в этом приложении обработано всего ~2600 методов. Новые методы будут появляться крайне редко (относительно количества вызовов этих методов), а, значит, можно не выполнять дорогостоящий анализ каждый раз.

GZ>Итак вооружившись этими тезисами, начинаю сочинять(играю как умею, в пианиста не стрелять).
Я пока поскипаю обсуждение конкретных предложений, т.к. не готов играть на равных

Здравствуйте, GlebZ, Вы писали:

GZ>Да я все это понимаю. Просто в описанных нами элементарных операциях мы не имеем возможности получить диапазон.
"Нами" — это кем? Лично я написал ровно тот набор операций, который реализован, к примеру, в MS SQL.
GZ>Зависит от того, что мы имеем ввиду под хеш-индексом. Их достаточно много. Тот что здесь — имеетRe[18]: Настольная БД

Автор: GlebZ
Дата: 05.04.06

.
Че-то я почитал-почитал, так и не понял, как это хэш индекс даст упорядоченность ключей.