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

S>Чтобы вызвать полиморфный метод, объект надо "поднять" в кэш.

По вашему, если методы будут в самой СУБД, то ей не прийдется поднимать в кэш такой объект при обработке запроса?

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

S>Здравствуйте, vdimas, Вы писали:
V>>А я намекал как раз на хеш-способ организации этих самых индексов в ФИЗИЧЕСКОЙ памяти. Ибо как раз они дают быстрый доступ и вставку. Немного непонятно, как ты собрался быстро вставлять в B-индекс? Если я не ошибаюсь, то надо двигать в памяти все миллионы вхождений индексируемого значения?
S>Ошибаешься. Во-первых, B+ дерево имеет логарифмическое время выполнения всех операций — вставки, удаления, и поиска. Ничего двигать вообще не надо. Хэши, применяемые в СУБД, устроены совсем не так, как ты привык видеть в памяти. Потому что там rehash с переливанием, предлагаемый тобой — это выстрел себе в ногу. Рекомендую ознакомиться с литературой. Например, есть неплохая книга Гарсиа-Молина со товарищи.

Я вообще-то говорил о реализации Hashtable в дотнете, так что твои рекомендации относятся к команде Microsoft.
И если ты следил за нитью разговора, то речь идет о хранении данных в ОП.

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

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

V>>Не смотришь в корень или я недостаточно выразил свою мысль. Мне, например, непонятно назначение индекса по суррогатному (логическому) ключу, если мне не нужен сам суррогатный ключ. ForeignKey иже с ним.
GZ>Очень простая причина. Уменьшение кол-ва задействованных объектов в алгоритме. Что касается foreignkey — то это не только правило ссылочной целостности, но и суррогатный индекс на ссылаемый аттрибут для быстрого его выполнения.

Блин, похоже все потеряли нить разговора. Речь-то идет о хранении данных в ОП. (о подобной гипотетической возможности). Дык, если все хранится в памяти произвольного доступа, то как суррогатный ключ мне поможет уменьшить кооличество задействованных объектов??? Вместо foreighkey вообще просто коллекция объектов на стороне master и ссылка на мастер на стороне detail (для one-to-many). Куда уж быстрее, если у меня и так все данные правильно сгруппированы и мне искать и выбирать ничего не надо, все уже выбрано и найдено.

V>>А я намекал как раз на хеш-способ организации этих самых индексов в ФИЗИЧЕСКОЙ памяти. Ибо как раз они дают быстрый доступ и вставку. Немного непонятно, как ты собрался быстро вставлять в B-индекс? Если я не ошибаюсь, то надо двигать в памяти все миллионы вхождений индексируемого значения?
GZ>Нет при вставке двигаются только в одно сегменте. То есть сложность почти как при поиске. При нехватке места — значения балансируются с соседними сегментами. Но он ни для одной операции не задействует все сегменты со значениями(кроме создания самого дерева, конечно).

V>>Хотя, говоря начистоту, мне способ реализации дотнетной хеш-таблицы не нравится. Мне больше нравится способ, где в каждом вхождении основной хеш-таблицы хранится сортированный массив. Подобные хеш-таблицы лучше предназначены для активной вставки/удаления большого числа элементов. Если будет не лень, то напишу подобный хеш и выложу для всеобщего пользования. (Писал когда-то именно такой на С++, ибо std::map не удовлетворял на больших наборах)

GZ>Каким образом ты собрался сортировать строки. Для хеша важно нормальное распределение значений. Для нормального распределения нужен функция хеширования. Но я не знаю функций хеширования которая могла бы оставлять информацию о порядке для сортировки.

Попробую пояснить. Хеш-функция и ф-ия сортировки — это разные ф-ии. Первая применяется для "разреживания" данных. Т.е. вместо одного бинарного индекса со временем доступа, кратным логирифму, у нас получается исходное время доступа, деленное на количество элементов в хеш-таблице (при удачно подобранной хеш-функции и соотв. данных).

Т.е. в моем способе, хеш-таблица — это массив массивов индексов. Обычно размер хеш-таблицы я беру такой, чтобы каждое ее вхождение содержало сортированный индекс от 2-х до 8-ми (грубо) ключей. В этом случае целессобразно сами индексы хранить как обычные сортированные последовательности и выполнять в них двоичный поиск.

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

GZ>С уважением, Gleb.

Здравствуйте, Alexey Rovdo, Вы писали:
AR>По вашему, если методы будут в самой СУБД, то ей не прийдется поднимать в кэш такой объект при обработке запроса?
Не обязательно. Я уже писал почему.

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

V>Блин, похоже все потеряли нить разговора. Речь-то идет о хранении данных в ОП. (о подобной гипотетической возможности). Дык, если все хранится в памяти произвольного доступа, то как суррогатный ключ мне поможет уменьшить кооличество задействованных объектов??? Вместо foreighkey вообще просто коллекция объектов на стороне master и ссылка на мастер на стороне detail (для one-to-many). Куда уж быстрее, если у меня и так все данные правильно сгруппированы и мне искать и выбирать ничего не надо, все уже выбрано и найдено.
Тут ты задвинул две проблемы. Допустим у нас есть нев.. ну в общем очень большой справочник операций сделанных над документами. Операций делаются по несколько тысяч за день. Можем ли мы сохранить ссылки на операции из документов? Нет не можем. Иначе у нас получится что связи (массив OID или указателей, как тебе будет угодно) намного больше чем сам документ. То есть, проблема избыточности связей существует (что в реляционке решается нормализацией). При этом есть такая шняга, что если документ убили, операции о нем не должны исчезнуть.
Вторая проблема которую ты решил не видеть. Нам нужно найти операции просмотра с определенным документом. Ну и что тут делать? Просматривать все операции? Не лучше ли поднять индекс и сделать это весело и быстро, чем тормозить и грустно
И таких примеров избыточности связей, когда память под связи на порядок больше чем сам объект, могу привести вагон.

С уважением, Gleb.

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

Специально выделил в отдельное сообщение поскольку немного отошли от основной темы (на усмотрение модераторов).

GZ>>Каким образом ты собрался сортировать строки. Для хеша важно нормальное распределение значений. Для нормального распределения нужен функция хеширования. Но я не знаю функций хеширования которая могла бы оставлять информацию о порядке для сортировки.

V>Попробую пояснить. Хеш-функция и ф-ия сортировки — это разные ф-ии. Первая применяется для "разреживания" данных. Т.е. вместо одного бинарного индекса со временем доступа, кратным логирифму, у нас получается исходное время доступа, деленное на количество элементов в хеш-таблице (при удачно подобранной хеш-функции и соотв. данных).

V>Т.е. в моем способе, хеш-таблица — это массив массивов индексов. Обычно размер хеш-таблицы я беру такой, чтобы каждое ее вхождение содержало сортированный индекс от 2-х до 8-ми (грубо) ключей. В этом случае целессобразно сами индексы хранить как обычные сортированные последовательности и выполнять в них двоичный поиск.
Для 2-8 ключей сортированный индекс не нужен.

V>Т.е. алгоритм такой:
V>берем хеш-фию и по ней находим ячейку хеш-таблицы. В этой ячейке хранится сортированная последовательность ключей, в которой мы выполняем бинарный поиск. На больших наборах данных такая организация хеш-таблицы ведет себя весьма достойно.
Ну особо-то от Microsoft не отличается.
За что я люблю B+ деревья, то что они универсальны для всех случаев. Максимум при поиске — Nlog(N) операций. Плюс хранение в сортированном виде.
Какие недостатки у кэша.
1. Сложность нахождения хеш-функции при которой есть нормальное распределение. Если у нас хорошая функция, то поиск происходит за O(1). Если плохая, то O(N).
2. При повторяемости данных — хеш теряет свои свойства.
3. При вставке большого кол-ва элементов — нужно расширять хеш таблицу. Иначе получаем O(N).
Microsoft решили вопрос кардинально. Повторяемость запрещена(что очень плохо). Поиск всегда O(1). Но за счет чего. За счет того, либо нужно сразу прогнозировать количество элементов и выделять память, либо при некоторых вставках сразу же получим неплохое торомжение. И есть возможность даже при выделенной памяти получить повторное хеширование всех элементов(что будет совсем хреново).
В твоем случае, почти все недостатки (как и у всех хешей) присутствует. И сразу еще одна — если мы допускаем что у нас до 8 одинаковых значений, то у нас нет особых гарантий и от 1000. То есть, приближаемся к O(N).

С уважением, Gleb.

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

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

V>>Блин, похоже все потеряли нить разговора. Речь-то идет о хранении данных в ОП. (о подобной гипотетической возможности). Дык, если все хранится в памяти произвольного доступа, то как суррогатный ключ мне поможет уменьшить кооличество задействованных объектов??? Вместо foreighkey вообще просто коллекция объектов на стороне master и ссылка на мастер на стороне detail (для one-to-many). Куда уж быстрее, если у меня и так все данные правильно сгруппированы и мне искать и выбирать ничего не надо, все уже выбрано и найдено.
GZ>Тут ты задвинул две проблемы. Допустим у нас есть нев.. ну в общем очень большой справочник операций сделанных над документами. Операций делаются по несколько тысяч за день. Можем ли мы сохранить ссылки на операции из документов? Нет не можем. Иначе у нас получится что связи (массив OID или указателей, как тебе будет угодно) намного больше чем сам документ. То есть, проблема избыточности связей существует (что в реляционке решается нормализацией). При этом есть такая шняга, что если документ убили, операции о нем не должны исчезнуть.
GZ>Вторая проблема которую ты решил не видеть. Нам нужно найти операции просмотра с определенным документом. Ну и что тут делать? Просматривать все операции? Не лучше ли поднять индекс и сделать это весело и быстро, чем тормозить и грустно

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

Такой подход был в свое время реализован в POET -- там при загрузке объекта можно было указывать, что делать с объектами по ссылкам: либо грузить все, либо грузить определенные типы ссылок. А в Goods, если мне не изменяет память, ссылки между объектами реализовывались на основе "умных указателей". И реальный доступ к объекту через умный указатель осуществлялся только тогда, когда было обращение по этому указателю.

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

V>>Т.е. алгоритм такой:
V>>берем хеш-фию и по ней находим ячейку хеш-таблицы. В этой ячейке хранится сортированная последовательность ключей, в которой мы выполняем бинарный поиск. На больших наборах данных такая организация хеш-таблицы ведет себя весьма достойно.
GZ>Ну особо-то от Microsoft не отличается.

Да ну ни хрена себе не отличается, принципиально по-другому...

GZ>За что я люблю B+ деревья, то что они универсальны для всех случаев. Максимум при поиске — Nlog(N) операций. Плюс хранение в сортированном виде.
GZ>Какие недостатки у кэша.
GZ>1. Сложность нахождения хеш-функции при которой есть нормальное распределение. Если у нас хорошая функция, то поиск происходит за O(1). Если плохая, то O(N).
GZ>2. При повторяемости данных — хеш теряет свои свойства.
GZ>3. При вставке большого кол-ва элементов — нужно расширять хеш таблицу. Иначе получаем O(N).
GZ>Microsoft решили вопрос кардинально. Повторяемость запрещена(что очень плохо). Поиск всегда O(1). Но за счет чего. За счет того, либо нужно сразу прогнозировать количество элементов и выделять память, либо при некоторых вставках сразу же получим неплохое торомжение. И есть возможность даже при выделенной памяти получить повторное хеширование всех элементов(что будет совсем хреново).
GZ>В твоем случае, почти все недостатки (как и у всех хешей) присутствует. И сразу еще одна — если мы допускаем что у нас до 8 одинаковых значений, то у нас нет особых гарантий и от 1000. То есть, приближаемся к O(N).

Я же русским языком сказал, что в ячейках хеш-таблицы хранятся сортированные индексы, в которых всегда поиск NLog(N).
Я все-таки буду писать подобную хеш-таблицу для второго дотнета (нужна самим подобная), учитывая твое замечание, предусмотрю в конструкторе фабрику для создания сортированных индексов в ячейках таблицы. Т.е., если будут подозрения плохое хеширование, можно подать фабрику для B+ индексов в ячейках. По умолчанию будет простой сортированный массив, в котором опять же трудоемкость не более NLog(N).

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

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

V>>Блин, похоже все потеряли нить разговора. Речь-то идет о хранении данных в ОП. (о подобной гипотетической возможности). Дык, если все хранится в памяти произвольного доступа, то как суррогатный ключ мне поможет уменьшить кооличество задействованных объектов??? Вместо foreighkey вообще просто коллекция объектов на стороне master и ссылка на мастер на стороне detail (для one-to-many). Куда уж быстрее, если у меня и так все данные правильно сгруппированы и мне искать и выбирать ничего не надо, все уже выбрано и найдено.
GZ>Тут ты задвинул две проблемы. Допустим у нас есть нев.. ну в общем очень большой справочник операций сделанных над документами. Операций делаются по несколько тысяч за день. Можем ли мы сохранить ссылки на операции из документов? Нет не можем. Иначе у нас получится что связи (массив OID или указателей, как тебе будет угодно) намного больше чем сам документ. То есть, проблема избыточности связей существует (что в реляционке решается нормализацией).

Бред, насчет нормализации. Здесь речь не об этом, а о том, где хранить индексы. Ты же не считаешь индекс в базе — избыточной информацией? Вот и здесь, подобный массив — суть индекс.


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

А никто не запрещает хранить связи вне объекта. Если мы рассматриваем ООСУБД полностью в памяти, то храни эти индексы там, где будешь использовать. Например в неком глобалдьном объекте DocumentsHistory.

GZ>При этом есть такая шняга, что если документ убили, операции о нем не должны исчезнуть.

Значит, документ физически не убит, а переведен в состояние "убит". Возможно, что при переходе в это состояние документ прочищает ненужные более подчиненные данные, оставляя лишь основные, либо же вообще, документ заменяется некоим стабом, несущим общую информацию о документе. В реальной базе я часто видел подобные стабы, и тут как раз имеем вовсю разгул избыточности. Т.е. в журнале документов фигурируют не сами документы, а "сокращенные" записи о них, типа {"Дата", "Сумма", "Корреспондент", "Кем создан"}. Если у нас подобный журнал документов хранит массив интерфейсов типа IDocumentInfo (который может имплементить как сам документ, так и потом "посмертный" стаб), то мы гораздо лучше избавляемся от избыточности данных. (в общем, в ООП совершенно другие подходы).

Тут есть еще один момент. Мы можем избавится от избыточности данных и в случае foreign key. Нам необязательно в подчиненном объекте иметь ссылку на ключ мастера. Т.е. для строк документа, кои не имеют смысла вне самого документа, мы можем ссылку на документ не хранить, ибо строки документа будут обрабатываться самим документом, который эти строки хранит. Т.е., в терминах реляционки, foreig key отсутствует, однако у нас есть индекс по нему и автоматически полученное ограничение целостности.

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

V>Бред, насчет нормализации.
Бредовые базы и в РСУБД встречаются. Например когда размер индексов 200% от размера БД. Такая шняга уже тормозит за счет индексов безбожно. Поэтому даже в плане нормализации и индексированности нужно соблюдать меру(хотя там и других проблем достаточно).
V>Здесь речь не об этом, а о том, где хранить индексы. Ты же не считаешь индекс в базе — избыточной информацией? Вот и здесь, подобный массив — суть индекс.
Разговор шел нужен ли индекс или нет. Возьми другую информацию, например дату, или тип операции. В любом случае, лучше чем декларативный язык запросов с жуткими механизмами оптимизации задачу поиска никто не решит.

V>А никто не запрещает хранить связи вне объекта. Если мы рассматриваем ООСУБД полностью в памяти, то храни эти индексы там, где будешь использовать. Например в неком глобалдьном объекте DocumentsHistory.
я в такой модели много полезного есть.

V>Значит, документ физически не убит, а переведен в состояние "убит". Возможно, что при переходе в это состояние документ прочищает ненужные более подчиненные данные, оставляя лишь основные, либо же вообще, документ заменяется некоим стабом, несущим общую информацию о документе. В реальной базе я часто видел подобные стабы, и тут как раз имеем вовсю разгул избыточности. Т.е. в журнале документов фигурируют не сами документы, а "сокращенные" записи о них, типа {"Дата", "Сумма", "Корреспондент", "Кем создан"}. Если у нас подобный журнал документов хранит массив интерфейсов типа IDocumentInfo (который может имплементить как сам документ, так и потом "посмертный" стаб), то мы гораздо лучше избавляемся от избыточности данных. (в общем, в ООП совершенно другие подходы).
Это уже частности. В 99 процентах случаев — ограничиваются логическим удалением. Лучше когда переносится в особый журнал (содержащий только нужную информацию). А иногда по требованиям — все кроме аудита must die. Без следов. Клиент всегда прав.

V>Тут есть еще один момент. Мы можем избавится от избыточности данных и в случае foreign key. Нам необязательно в подчиненном объекте иметь ссылку на ключ мастера.
Наоборот. Мастер хранит коллекцию ссылок на подчиненные объекты.
V>Т.е. для строк документа, кои не имеют смысла вне самого документа, мы можем ссылку на документ не хранить, ибо строки документа будут обрабатываться самим документом, который эти строки хранит. Т.е., в терминах реляционки, foreig key отсутствует, однако у нас есть индекс по нему и автоматически полученное ограничение целостности.
Нормальная ситуация для OODB. Со своими плюсами и недостатками. Особенно если этих строк 10000.

С уважением, Gleb.

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

C>Sinclair пишет:

>> C>Из-за дьявольски сложного семейства почтовых стандартов.
>> Я же сказал "банального"

C>Слова "банальный", "корректный" и "email" — несовместимы. Даже банальный
C>релей должен понимать все форматы адресов, если хочет быть корректным.

Ага, там самая веселуха начинается, когда надо залезть внутрь письма, например подпись вставить

GZ>Это уже частности. В 99 процентах случаев — ограничиваются логическим удалением. Лучше когда переносится в особый журнал (содержащий только нужную информацию).

Если переносится в отдельный журнал, то невозможно задать ограничения целостности. А в моем варианте, при имплементации IDocumentInfo — запросто.

GZ>А иногда по требованиям — все кроме аудита must die. Без следов. Клиент всегда прав.

Аудита чего? Все-равно хоть какая-то инфа должна остаться, иначе сама history не нужна.

V>>Тут есть еще один момент. Мы можем избавится от избыточности данных и в случае foreign key. Нам необязательно в подчиненном объекте иметь ссылку на ключ мастера.
GZ>Наоборот. Мастер хранит коллекцию ссылок на подчиненные объекты.
V>>Т.е. для строк документа, кои не имеют смысла вне самого документа, мы можем ссылку на документ не хранить, ибо строки документа будут обрабатываться самим документом, который эти строки хранит. Т.е., в терминах реляционки, foreig key отсутствует, однако у нас есть индекс по нему и автоматически полученное ограничение целостности.
GZ>Нормальная ситуация для OODB. Со своими плюсами и недостатками. Особенно если этих строк 10000.

нормальная вполне ситуация, когда подчиненных строк не более 10000 в документе.

GZ>С уважением, Gleb.

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

М>>Пример в студию?
S>Re[23]: Объектные базы как они есть

Автор: Sinclair
Дата: 07.04.05

Теперь понятно.
имхо это не есть хорошая идея — вот так смешивать SQL и объектную базу.
Если это так надо: IPerson и т.п. должны жить где-то внутри движка СУБД. Так же как план запроса живет внутри оракла.
Кстати, на SQL мир клином не сошелся. Хотя к сожалению, этот шаблон сильно влияет на образ мышления.
Во многих задачах можно жить и без него.
Например, см. http://www.cronos.ru

Здравствуйте, Михаил, Вы писали:
М>Теперь понятно.
М>имхо это не есть хорошая идея — вот так смешивать SQL и объектную базу.
А с чем надо смешивать объектную базу?
М>Если это так надо: IPerson и т.п. должны жить где-то внутри движка СУБД. Так же как план запроса живет внутри оракла.
Совершенно верно.
М>Кстати, на SQL мир клином не сошелся. Хотя к сожалению, этот шаблон сильно влияет на образ мышления.
Гм. Не вижу ничего плохого в SQL. Наоборот — практика показывает, что на нем гораздо труднее заставить сервер заниматься непроизводительной работой. А императивно это сделать очень легко.

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

E>Имхо, такие проблемы лечатся, если поднятие объекта из БД не означает автоматического поднятия всех объектов по его ссылкам. Тогда, для приведенного примера, в объекте-документе может быть ссылка на объект-историю. А уже в истории будет храниться список модификаций (тем или иным образом организованный). Если объект-документ извлекается из БД без объекта-истории, то нет проблем с производительностью.

E>Такой подход был в свое время реализован в POET -- там при загрузке объекта можно было указывать, что делать с объектами по ссылкам: либо грузить все, либо грузить определенные типы ссылок. А в Goods, если мне не изменяет память, ссылки между объектами реализовывались на основе "умных указателей". И реальный доступ к объекту через умный указатель осуществлялся только тогда, когда было обращение по этому указателю.

Речь идет не о поднятии связанных объектов при загрузке объекта, а о поднятии самих ссылок на эти связанные объекты. Проблема "избыточности связей", как правильно заметил GlebZ, ИМХО, существует.

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

GZ>Тут ты задвинул две проблемы. Допустим у нас есть нев.. ну в общем очень большой справочник операций сделанных над документами. Операций делаются по несколько тысяч за день. Можем ли мы сохранить ссылки на операции из документов? Нет не можем. Иначе у нас получится что связи (массив OID или указателей, как тебе будет угодно) намного больше чем сам документ. То есть, проблема избыточности связей существует (что в реляционке решается нормализацией). При этом есть такая шняга, что если документ убили, операции о нем не должны исчезнуть.

Здесь я бы поставил вопрос по другому: Должны ли все связи в домейн-модели быть двунаправленные? Больной, так сказать, для меня вопрос.

GZ>Вторая проблема которую ты решил не видеть. Нам нужно найти операции просмотра с определенным документом. Ну и что тут делать? Просматривать все операции? Не лучше ли поднять индекс и сделать это весело и быстро, чем тормозить и грустно

Я так понял, что главным здесь является "операции просмотра". То есть необходимо выбрать не все, а только часть операций по определенному критерию.

Когда мы говорим о связях, которые определяются структурой объектов домейн-модели, то ИМХО мы говорим о проблемах навигационного доступа. Твой пример с выборкой операций просмотра — это ассоциативный доступ, т.е. к организации связей имеет мало отношения. Этим должен заниматься язык запросов, а это уже совсем другая тема.

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

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

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

E>>Имхо, такие проблемы лечатся, если поднятие объекта из БД не означает автоматического поднятия всех объектов по его ссылкам. Тогда, для приведенного примера, в объекте-документе может быть ссылка на объект-историю. А уже в истории будет храниться список модификаций (тем или иным образом организованный). Если объект-документ извлекается из БД без объекта-истории, то нет проблем с производительностью.

E>>Такой подход был в свое время реализован в POET -- там при загрузке объекта можно было указывать, что делать с объектами по ссылкам: либо грузить все, либо грузить определенные типы ссылок. А в Goods, если мне не изменяет память, ссылки между объектами реализовывались на основе "умных указателей". И реальный доступ к объекту через умный указатель осуществлялся только тогда, когда было обращение по этому указателю.

S>Речь идет не о поднятии связанных объектов при загрузке объекта, а о поднятии самих ссылок на эти связанные объекты. Проблема "избыточности связей", как правильно заметил GlebZ, ИМХО, существует.

Если ссылки вынести в отдельный объект, то задача сводится с тому, о чем я написал

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

E>Если ссылки вынести в отдельный объект, то задача сводится с тому, о чем я написал

Здесь проблема не только в чтении ссылок. Если речь идет о двунаправленной связи, то есть еще и проблема синхронного изменения. То есть, возмем пример рассматриваемый выше: документ и операции с ним. Документ хранит коллекцию ссылок на свои операции, а операция — ссылку на документ.
Так вот, например, я загрузил операцию (или мне ее вернула какая-нибудь функция) и решил изменить у нее ссылку на документ. То есть переприсвоить операцию другому документу (пример, конечно неудачный, но...). Я же должен соответствующие изменения сделать и в коллекциях ссылок старого и нового документа. Т.е. все равно эти коллекции сначала придется подгрузить. Так что выделяй в отдельный объект или нет — без разницы.

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

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

E>>Если ссылки вынести в отдельный объект, то задача сводится с тому, о чем я написал

S>Здесь проблема не только в чтении ссылок. Если речь идет о двунаправленной связи, то есть еще и проблема синхронного изменения. То есть, возмем пример рассматриваемый выше: документ и операции с ним. Документ хранит коллекцию ссылок на свои операции, а операция — ссылку на документ.
S>Так вот, например, я загрузил операцию (или мне ее вернула какая-нибудь функция) и решил изменить у нее ссылку на документ. То есть переприсвоить операцию другому документу (пример, конечно неудачный, но...). Я же должен соответствующие изменения сделать и в коллекциях ссылок старого и нового документа. Т.е. все равно эти коллекции сначала придется подгрузить. Так что выделяй в отдельный объект или нет — без разницы.

Что-то я не очень понимаю в чем суть проблемы. Если по условиям задачи возможно, что в объекте "операция над документом" можно поменять ссылку на изменяемый документ (что само по себе странно), то можно организовать коллекцию ссылок таким образом, чтобы операции вставки/удаления были дешевыми. Например, вместо вектора ссылок использовать двусвязный список (каждый элемент содержит собственно ссылку + ссылки на предыдущий/следующий элементы списка) или map на основе B+ дерева.

Имхо, ситуация здесь точно такая же, как при работе со структурами в ОП. Мы можем пренебречь скоростью некоторых операций (т.к. как удаления операций из истории) и выбрать более эффективный в смысле расхода памяти контейнер для хранения ссылок (вектор). А можем наоборот, постараться обеспечить высокую скорость за счет высокой ресурсоемкости (списки, деревья).

Здравствуйте, stalcer, Вы писали:
S>И еще один хитрый вопрос — должны ли связи быть частью объекта, или же они должны быть отдельными сущностями, возможно (а может и нет) отдельно грузиться, отдельно сохраняться, а самое главное — отдельно объявляться.
Как ты, однако, вопросы-то верно ставишь!
С одной стороны, нутряное чутье подсказывает — если интерфейс объекта публикует связь, то пусть публикует:

public interface ICustomerOrder
{
  ICustomer Customer { get;}
}

Как, впрочем, и обратный интерфейс:

public interface ICustomer
{
  IEnumerable<IOrder> Orders();
}

В отсутствие ассоциативного доступа ясно, что реализациям этих интерфейсов придется хранить встречные ссылки. Поддержка ассоциативного доступа предлагает выбор между:

public CustomerOrder: ICustomerOrder
{
  public ICustomer Customer { 
        get
        {
            return Engine.Select("ICustomer customer where customer.Orders.Contains(this)")[0];
        }
    }
}

и

public Customer: ICustomer
{
  public IEnumerable<IOrder> Orders()
    {
        return Engine.Select("IOrder order where Customer = this");
    }
}

Подразумевается, что ответная сторона связи хранит поле соответствующего типа.

С третьей стороны, мы вряд ли сможем предусмотреть все связи на этапе проектирования системы. Особенно если это хорошая, модульная система. И вот у нас есть модуль A (с интерфейсом, скажем, IPerson) и модуль B (c интерфейсом, скажем, IVehicle). Эти модули — от разных производителей, которые знать друг про друга не знают. А мы теперь должны с построить композитную систему, отслеживающую факт принадлежности автомобилей персонам, с минимальным геморроем и максимальным повторным использованием.
У нас есть уже три варианта:
1. Наследуемся от готовой реализации IPerson; расширяем ее интерфейсом

IVehicleOwner:
{
  IEnumerable<Vehicle> Vehicles();
}

вкупе с соответствующей реализацией хранения списка ссылок на движимое имущество.
2. Обратный вариант — расширяем реализацию IVehicle до IOwnedVehicle: IVehicle, IOwnedObject.
3. Не трогаем реализации вообше. Вместо этого создаем новый хранимый тип

public ClassPersonToVehicleLink
{
  public IPerson Person {get; set;}
    public IVehicle Vehicle {get; set;}
}

Третий вариант наименее зависим от модулей A и B. Это значит, что потом мы легким движением руки добавим или заменим модуль B модулем B1, где предоставлена альтернативная реализация IVehicle. Таким образом, шансы на повторное использование нашего модуля С резко возрастают.

Вот такая вот петрушка получается. Кстати, третий подход никак не противоречит изобретению интерфейсов IVehicleOwner и IOwnedVehicle и их реализации. Если это где-то будет удобно — нет проблем.