Здравствуйте, Borisman2, Вы писали:
B>Сразу оговорюсь, сейчас я зол, раздражен и раздосадован. Поэтому могу немного того... необъективно выражаться.
Ок, не проблема
B>Столь же эффективный ассоциативный доступ предполагает соотвтетствие "ключ"->"объект",
Гм. Вообще-то под ассоциативным доступом понимают несколько более широкое понятие. Ассоциативный доступ — это доступ на основе свойств объекта, а не его identity. Именно поддержка ассоциативного доступа сделала РСУБД такими популярными. Ты пользуешься ассоциативным доступом почти всякий раз, как выполняешь запрос по неуникальным атрибутам:

select * from Employee where salary > 500

B>что приводит нас ко всем известным РСУБД как это не печально.
Этого я не понял. Да, в РСУБД ассоциативный доступ реализован. И круто то, что он реализован эффективно: современный оптимизатор запросов учитывает столько деталей, что редкий DBA способен увеличить производительность (без пересмотра схемы данных). Но почему так печально? Я-то и спрашиваю "а если этот доступ будет реализован естественным образом?"
B>Т.е. в принципе, конечно, можно сделать такую фичу. И будет работать, и хорошо будет работать (может быть).
Ну, вот я как бы не вижу непреодолимых проблем сделать эту фичу Преодолимые есть — пытаюсь преодолеть.
B>И так и делают обычно, как я понял...
Ну, я что-то не встречал полноценного движка запросов в полноценной объектной среде. Самый полноценный — Gemstone, но и он сильно ограничен.
B>Но зачем ??? Зачем вообще тогда объекты и сложная навигация между ними ?
Ну, мне лично кажется, что сложные взаимосвязи объектам нужны для того, чтобы обеспечивать сложное поведение. ООП предлагает достаточно продвинутые средства декомпозиции (уж по крайней мере более продвинутые, чем SQL-ориентированные СУБД).
B>Кто будет создавать ключи ? Если ООБД, то ключи будут иметь неудобоваримый вид (как, например, OID). Если пользователь, то какая же это ООБД ?
B>Или я чересчур драматизирую ?
По-моему, я невнятно выразился. Что ты называешь ключами? Я имею в виду банальную поддержку запросов вида

public IEnumerable<IEmployee> GetHighPayedEmployees()
{
  return Extent<IEmployee>.Select(delegate(IEmployee self)
    {
      return (self.Salary>500);
    });
}

Это близкий к реальному код на C# 2.0. При этом независимо от количества реализаций интерфейса IEmployee результирующая коллекция будет содержать все удовлетворяющие условию объекты.
При этом по полям реальных классов можно будет строить индексы, которые будут автоматически использоваться движком так же, как это происходит в RDBMS.
B>А в общем говоря, проблема ведь не в ключах, а в том, что диаграммами классов по факту очень трудно описывать предметную область.
Ну вот это уже другой вопрос.
B>Слишком уж строгие ограничения налагает иерархия классов на объекты. В реальном мире все может быть гораздо гибче.

B>Насчет навигационной сущности ООП, как правильно заметил этот (собака!) B. Jacobs здесь : http://www.geocities.com/tablizer/core1.htm
Я вроде понял рассуждения собаки Якобса. Я пытаюсь понять — что будет, если мы реализуем альтернативу навигационному доступу?