Если речь идет о большой системе, если она модульная, и если пишется совместно многими программистами, то двунаправленные связи в домейн-модели, если они вшиты в доменные классы будут представлять из себя большой геморрой, так как будут вносить много зависимостей между модулями на логическом уровне доменной модели. И что самое противное — циклических зависимостей.
И вторая проблема, как ты правильно написал, если есть две подсистемы и их объекты никак не связаны, а связываются они только в третьей подсистеме, то велика вероятность, что эта связь в достаточно большом количестве подзадач задействована не будет и ее было бы неправильно засовывать в объекты, чисто с точки зрения производительности/памяти.
Вот и возникает мысль о том что объявлять связи нужно отдельно от классов доменных объектов. И даже может не только объявлять, но и кэшировать как-то в отдельных структурах, а не при помощи перекрестных ссылок (коллекций ссылок).
Только вот я тут думаю уже на протяжении полугода как бы это сделать. Уж больно все сложно получается. Так — что у меня крыша съезжает .
Здравствуйте, eao197, Вы писали:
E>Что-то я не очень понимаю в чем суть проблемы. Если по условиям задачи возможно, что в объекте "операция над документом" можно поменять ссылку на изменяемый документ (что само по себе странно), то можно организовать коллекцию ссылок таким образом, чтобы операции вставки/удаления были дешевыми. Например, вместо вектора ссылок использовать двусвязный список (каждый элемент содержит собственно ссылку + ссылки на предыдущий/следующий элементы списка) или map на основе B+ дерева.
А я не про организацию в памяти говорю, а про то, что чтобы изменить эту коллекцию в памяти (пусть и бытрым алгоритмом) ее нужно сначала подчитать из базы. Т.е. вроде как бы изначально то я хотел переприсвоить только одну ссылку, но поскольку связь двунаправленная — неявно подгрузиться коллекция с обратной стороны. Ето вот проблема.
Здравствуйте, stalcer, Вы писали:
S>Здравствуйте, eao197, Вы писали:
E>>Что-то я не очень понимаю в чем суть проблемы. Если по условиям задачи возможно, что в объекте "операция над документом" можно поменять ссылку на изменяемый документ (что само по себе странно), то можно организовать коллекцию ссылок таким образом, чтобы операции вставки/удаления были дешевыми. Например, вместо вектора ссылок использовать двусвязный список (каждый элемент содержит собственно ссылку + ссылки на предыдущий/следующий элементы списка) или map на основе B+ дерева.
S>А я не про организацию в памяти говорю, а про то, что чтобы изменить эту коллекцию в памяти (пусть и бытрым алгоритмом) ее нужно сначала подчитать из базы. Т.е. вроде как бы изначально то я хотел переприсвоить только одну ссылку, но поскольку связь двунаправленная — неявно подгрузиться коллекция с обратной стороны. Ето вот проблема.
Нет, это проблема, только если выбранная коллекция требует для своего изменения полной загрузки себя в память. Например, если коллекция -- это вектор (непрерывная последовательность ссылок). А если коллекция -- это дерево, то в память нужно будет загрузить только вершину и те промежуточные узлы, которые ведут к модифицируемому узлу. И если речь идет о B+ дереве, например, то изятие одного элемента из дерева в несколько миллионов элементов потребует доступа всего к нескольким узлам (страницам) дерева.
... << RSDN@Home 1.1.4 beta 5 rev. 395>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, Sinclair, Вы писали:
S>Кстати, третий подход никак не противоречит изобретению интерфейсов IVehicleOwner и IOwnedVehicle и их реализации. Если это где-то будет удобно — нет проблем.
Я вот думаю про свой доменный язык. Хочу сделать по аналогии с Helper'ами из Delphi 8 — 2005. Там же функциональность TObject заложена в helper, а доступна прямо через объект. Вот также надо, чтобы связь объявлялась отдельно, а доступна была обычным образом:
Типа объявляем так:
Первый модуль:
persistent class Customer
{
//...
}
Второй модуль:
persistent class Order
{
//...
}
В третем модуле:
persistent association CustomerOrders
{
role Customer.Orserds;
role Order.ParentCustomer;
}
А потом где-то в четвертом модуле можно использовать так:
Customer c = getCustomer(...);
int ordcnt = c.Orserds.Count;
То есть если этот четвертый модуль видит объявление ассоциации CustomerOrders, то компилятор позволяет писать прямо через точку.
Получаются зависимости:
3 -> 1
3 -> 2
4 -> 1
4 -> 2 4 -> 3
То есть такие, какие и должны быть по смыслу.
Здравствуйте, eao197, Вы писали:
E>Нет, это проблема, только если выбранная коллекция требует для своего изменения полной загрузки себя в память. Например, если коллекция -- это вектор (непрерывная последовательность ссылок). А если коллекция -- это дерево, то в память нужно будет загрузить только вершину и те промежуточные узлы, которые ведут к модифицируемому узлу. И если речь идет о B+ дереве, например, то изятие одного элемента из дерева в несколько миллионов элементов потребует доступа всего к нескольким узлам (страницам) дерева.
Я о чем и говорю: коллекции в таком случае должны быть построены так, чтобы не нужно было подгружать ее вообще. Может быть даже просто запоминать все изменения в какой-то другой структуре, для того чтобы когда коллекция реально потребуется — загрузить ее (коллекцию) и скорректировать.
Тут еще фишка в том, что в большинстве случаев коллекции — маленькие и без разницы грузить ее всю или только часть. Это все равно одно обращение к базе. А вот если совсем не грузить , это да, это хорошо.
А еще может быть и обратная ситуация. Когда коллекция уже загружена, и из нее, например, удаляем объект. Или еще круче: делаем просто Clear(). И прикинь, что для этого необходимо будет подгрузить все соответствующие children объекты, чтобы изменить в них ссылки.
А ведь и та и другая ситуация может быть с равной вероятностью. И придумать алгоритм, который бы не грузил лишнее в обоих случаях — вот хитрая задачка.
Здравствуйте, stalcer, Вы писали:
S>А ведь и та и другая ситуация может быть с равной вероятностью. И придумать алгоритм, который бы не грузил лишнее в обоих случаях — вот хитрая задачка.
Имхо, это из области нахождения компромиса между скоростью/ресурсоемкостью.
По отношению к ООСУБД более интересно другое: должны ли эти алгоритмы быть частью ООСУБД или ООСУБД должна предоставлять средства для их эффективной реализации на прикладном уровне?
... << RSDN@Home 1.1.4 beta 5 rev. 395>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
E>Имхо, это из области нахождения компромиса между скоростью/ресурсоемкостью.
Да, но нужно подмать как бы исхитриться и т.п. Может чего и получится .
E>По отношению к ООСУБД более интересно другое: должны ли эти алгоритмы быть частью ООСУБД или ООСУБД должна предоставлять средства для их эффективной реализации на прикладном уровне?
Если само понятие двунаправленных связей — определено в ООСУБД, то да, должны быть частью ООСУБД. По моему, двунаправленные связи совсем не лишние в ООСУБД. Наоборот, очень естественно иметь объекты и связи между ними. И к UML ближе. Ссылочные аттрибуты, в каком-то смысле, более надуманное понятие.
М>>имхо это не есть хорошая идея — вот так смешивать SQL и объектную базу. S> А с чем надо смешивать объектную базу?
не базу смешивать, а скорее языки, и не смешивать, а изменять (мне так кажется):
РСУБД-О/РСУБД — SQL
ООСУБД — OQL
М>>Кстати, на SQL мир клином не сошелся. Хотя к сожалению, этот шаблон сильно влияет на образ мышления. S>Гм. Не вижу ничего плохого в SQL. Наоборот — практика показывает, что на нем гораздо труднее заставить сервер заниматься непроизводительной работой. А императивно это сделать очень легко.
Ничего плохого в SQL и нет, просто это язык работы с реляционными данными, а для объектных есть OQL
E>>По отношению к ООСУБД более интересно другое: должны ли эти алгоритмы быть частью ООСУБД или ООСУБД должна предоставлять средства для их эффективной реализации на прикладном уровне?
S>Если само понятие двунаправленных связей — определено в ООСУБД, то да, должны быть частью ООСУБД. По моему, двунаправленные связи совсем не лишние в ООСУБД. Наоборот, очень естественно иметь объекты и связи между ними. И к UML ближе. Ссылочные аттрибуты, в каком-то смысле, более надуманное понятие.
ООСУБД не должна содержать такие алгоритмы, так как учет всех таких ситуаций (и способов их решения) приведет к разрастанию такой СУБД до махины, в которой ни Вы, ни я, ни кто-либо вообще не разберется. Так что мне кажется достаточно (более чем) просто предоставить инструменты создания таких алгоритмов. Например, Versant VDS поддерживает B+ (т.е когда для коллекции можно указать, что ее надо хранить в B+) — вот пример наличия инструментов (предоставляемых) для реализации алгоритмов оптимизации хранения.
Здравствуйте, BaZa, Вы писали:
е базу смешивать, а скорее языки, и не смешивать, а изменять (мне так кажется): BZ>РСУБД-О/РСУБД — SQL BZ>ООСУБД — OQL
Угу. А еще я туда ем. BZ>Ничего плохого в SQL и нет, просто это язык работы с реляционными данными, а для объектных есть OQL Стандарт OQL — основная причина фиаско ODBMS.
... << RSDN@Home 1.1.4 beta 5 rev. 395>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S> Стандарт OQL — основная причина фиаско ODBMS.
Ну это вы уже загнули. Наверное, если бы вы сказали "... основная причина фиаско ODMG", я бы еще согласился. Но с точки зрения ООСУБД наличие или отсутствие поддержки OQL само по себе ничего не меняет. Просто OQL — далеко не самый удобный способ выборки объектов "по значению" из тех, что доступны в современных ООСУБД. Лично я уже описывал свои сомнения в целесообразности использования декларативных языков запросов в работе с ООСУБД, но раз уж он (OQL) есть, то никак не вредит одним лишь своим присутствием.
S>Угу. А еще я туда ем. BZ>>Ничего плохого в SQL и нет, просто это язык работы с реляционными данными, а для объектных есть OQL S> Стандарт OQL — основная причина фиаско ODBMS.
ну, это сильно сказано. Хотя, возможно, в этом есть доля правды — именно из подобных соображений производители ООСУБД реализуют его не по ODMG 3, а исходя из соображений usability и пр.
На самом деле OQL лучше всего описан во втором ODMG (по крайней мере по сравнению с третим)
Здравствуйте, BaZa, Вы писали:
BZ>На самом деле OQL лучше всего описан во втором ODMG (по крайней мере по сравнению с третим)
А у тебя есть третья спецификация?
Здравствуйте, BaZa, Вы писали:
BZ>ООСУБД не должна содержать такие алгоритмы, так как учет всех таких ситуаций (и способов их решения) приведет к разрастанию такой СУБД до махины, в которой ни Вы, ни я, ни кто-либо вообще не разберется. Так что мне кажется достаточно (более чем) просто предоставить инструменты создания таких алгоритмов. Например, Versant VDS поддерживает B+ (т.е когда для коллекции можно указать, что ее надо хранить в B+) — вот пример наличия инструментов (предоставляемых) для реализации алгоритмов оптимизации хранения.
Нет уж, простите. Речь же шла о кэшировании связей. Этим СУБД очень как должна заниматься. Или вы предлагаете вообще отказаться от двунаправленных связей — как понятия? И переложить их организацию на плечи прикладного программиста? А СУБД будет только поддерживать ссылки и коллекции (ссылок)?
Так что если понятие двунаправленных связей вкладывать в ООСУБД, то все эти алгоритмы должны присутствовать. ИМХО ничего не будет разрастаться, просто вдобавок к одному базовому понятию — объект (класс), будет еще и другое — связь (ассоциация). И я специально подчеркнул, что даже UML на это пошел. Так что не вижу здесь ничего страшного. А полезного — вижу много.
Здравствуйте, stalcer, Вы писали:
S>Здравствуйте, BaZa, Вы писали:
BZ>>ООСУБД не должна содержать такие алгоритмы, так как учет всех таких ситуаций (и способов их решения) приведет к разрастанию такой СУБД до махины, в которой ни Вы, ни я, ни кто-либо вообще не разберется. Так что мне кажется достаточно (более чем) просто предоставить инструменты создания таких алгоритмов. Например, Versant VDS поддерживает B+ (т.е когда для коллекции можно указать, что ее надо хранить в B+) — вот пример наличия инструментов (предоставляемых) для реализации алгоритмов оптимизации хранения.
S>Нет уж, простите. Речь же шла о кэшировании связей. Этим СУБД очень как должна заниматься. Или вы предлагаете вообще отказаться от двунаправленных связей — как понятия? И переложить их организацию на плечи прикладного программиста? А СУБД будет только поддерживать ссылки и коллекции (ссылок)?
S>Так что если понятие двунаправленных связей вкладывать в ООСУБД, то все эти алгоритмы должны присутствовать. ИМХО ничего не будет разрастаться, просто вдобавок к одному базовому понятию — объект (класс), будет еще и другое — связь (ассоциация). И я специально подчеркнул, что даже UML на это пошел. Так что не вижу здесь ничего страшного. А полезного — вижу много.
Связи не имеют имени. Вместо этого именуются навигационные пути (traversal paths) для каждого направления навигации, например профессор преподает (teaches) совокупность разделов курсов, инверсное направление определяется тем, что разделы курсов преподаются (is_taught_by) профессорами. Эти имена объявляются в определениях интерфейсов, соответствующих типам, участвующим в связи:
interface Professor { ...
teaches: Set<Section> inverse Section::is_taught_by
}
и
interface Section { ... is_taught_by: Professor inverse Professor::teaches
}
Для типа связи 1-n определены следующие операции:
— create(o1:Denotable_Object, s:Set<Denotable_Object>);
— delete ();
— add_one_to_one (o1:Denotable_Object, o2:Denotable_Object);
— remove_one_to_one (o1:Denotable_Object, o2:Denotable_Object);
— traverse (from:Denotable_Object) -> s: Set<Denotable_Object>.
При этом, как я себе это предствлял, изменение множества Professor::teaches автоматически приведет к модификации соответствующих Section::is_taught_by.
Но здесь в дело вступает другой момент: насколько эффективной должна быть реализация Set<...> inverse на уровне ООСУБД? Ведь могут быть разные случаи: когда множество маленькое и его лучше представлять в виде вектра или, наоборот, множество может быть очень большим (как в случае с обсуждаемым нами примером документа и истории его изменений). Кто должен выбирать, как Set<...> должна быть реализовано?
Я понял BaZa так, что если пойти на реализацию на уровне ООСУБД различный вариантов контейнеров связей (SmallSet, BTreeSet, HugeSet, SmallList, HugeList, ...), то такая ООСУБД действительно будет вынуждена поддерживать массу функциональности. Например, на уровне поддержки эволюции схемы данных нужно будет поддержать преобразование атрибута Professor::teaches из SmallSet в BTreeSet и обратно.
Может быть более выгодным способом будет предоставление одного типа связи dual_ref? А все остальное делать на основе этой связи и стандартных или нестандартных контейнеров? Например:
Сейчас подумалось, что ООСУБД по выражению dual_ref< Professor::teaches > трудно будет понять, что в контейнере Set находятся ссылки. Ведь если нет специального типа "множество ссылок", а есть только контейнеры, то могут быть контейнеры контейнеров и др. И как во всем этом нужные ссылки искать? М-да...
... << RSDN@Home 1.1.4 beta 5 rev. 395>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Но, ведь релляционные базы как-то с этим справляются. Ведь там тоже таблица может быть маленькой или большой. И планы выполнения запроса получаются разные: FULL-SCAN или INDEX-SEARCH. Но, какой-то внутренний формат, используемый СУБД все равно есть. И работает он с обеими ситуациями.
Я вообщем-то и не предлагаю выставлять наружу различные типы коллекций (SmallSet, BTreeSet, HugeSet, SmallList, HugeList, ...). Я именно и предлагаю подумать, как это все можно унифицировать. Именно с точки зрения эффективности СУБД.
Одно из требований (желаний) я определил: Надо сделать так, чтобы при изменении одного конца связи не нужно было грузить всю коллекцию (или объект со ссылкой) на другом конце.
Здравствуйте, stalcer, Вы писали:
S>Здравствуйте, eao197, Вы писали:
S>Но, ведь релляционные базы как-то с этим справляются. Ведь там тоже таблица может быть маленькой или большой. И планы выполнения запроса получаются разные: FULL-SCAN или INDEX-SEARCH. Но, какой-то внутренний формат, используемый СУБД все равно есть. И работает он с обеими ситуациями.
Реляционные базы -- это совсем другая песня. Там ведь вообще нет возможности напрямую объект в БД запихнуть. Нужно либо делать это ручками (тогда у нас нет как такового атрибута множество ссылок на изменения документа, а есть несколько SQL запросов на сериализацию/десериализацию этого атрибута). И тогда мы получаем возможность гибко управлять ссылками, т.к. мы можем делать небольшие запросы, изменяющие только часть ссылок.
Либо нужно воспользоваться инструментами O/R Mapping-а. И тогда получаются теже самые SQL запросы, но вот насколько мы их контролируем и насколько эффективно они будут обрабатывать подобные изменения ссылок -- второй вопрос. Поскольку я не специалист в O/R Mapping-е, то ничего по этому поводу не скажу.
S>Я вообщем-то и не предлагаю выставлять наружу различные типы коллекций (SmallSet, BTreeSet, HugeSet, SmallList, HugeList, ...). Я именно и предлагаю подумать, как это все можно унифицировать. Именно с точки зрения эффективности СУБД.
S>Одно из требований (желаний) я определил: Надо сделать так, чтобы при изменении одного конца связи не нужно было грузить всю коллекцию (или объект со ссылкой) на другом конце.
Но тогда нужно определить еще и условия, при которых этого не нужно делать. Ведь если все коллекции ссылок будут обрабатываться таким образом независимо от их размера, то накладные расходы на хранение этих коллекций могут оказаться слишком высокими.
... << RSDN@Home 1.1.4 beta 5 rev. 395>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
S>>Одно из требований (желаний) я определил: Надо сделать так, чтобы при изменении одного конца связи не нужно было грузить всю коллекцию (или объект со ссылкой) на другом конце.
E>Но тогда нужно определить еще и условия, при которых этого не нужно делать. Ведь если все коллекции ссылок будут обрабатываться таким образом независимо от их размера, то накладные расходы на хранение этих коллекций могут оказаться слишком высокими.
В базах данных, в этом смысле, есть один очень положительный момент: основное время тратиться на работу с диском. Это само по себе, конечно очень плохо, но зато можно не экономить на работе в кэше. То есть формат данных в кэше можно сделать и более навороченным, по сравнению, например, со стандартными коллекциями C++.
В данном конкретном случае — всегда нужно стремиться к тому, чтобы не загружать зря коллекцию с другой стороны. Так как накладные расходы на загрузку будут несоизмеримо больше, чем работа с кэшем.
.
, это да, это хорошо.
.
А с чем надо смешивать объектную базу?
Стандарт OQL — основная причина фиаско ODBMS.
