Андрей ЛеонидовичВот я и предполагаю, Victor Metelitsa, что ХУЖЕ Вас понимаю ООСУБД. И задаю совершенно безобидный конкретный вопрос:

Как, например, в "вашей" ООСУБД представляются связи между сущностями многие-ко-многим, когда у них (связей) есть свои свойства (характеристики)? Как в РСУБД ?

И не получаю (вполне ожидаемо) на него конкретного ответа.


Почему "вполне ожидаемо"? Вам просто надо было немного (или много) больше подумать над тем, что я сказал.


Пример из соседней дискуссии (НРМ):

Товар <--- Хранится на/Хранит ---> Склад

Эта связь многие-ко-многим имеет характеристики, например, количество (товара на складе).


То, что вы хотите, вполне очевидно раскладывается на связи 1:N (Товар <--- Хранится на/Хранит) и N:1 (Хранится на/Хранит ---> Склад) между экземплярами классов "Товар", "Хранится на/Хранит", "Склад"


И уж заодно еще более простой вопрос: семантика связей хранится на уровне метаданных в ООСУБД GemStone?

Там нет понятия "связей". Есть объекты, они знают о других объектах - вот и всё.

vadiminfo...
Имеется Кэево определение (1. есть только объекты 2. объекты общаются между собой посредством сообщений). Именно он придумал термин и его определение. Можете спросить его лично. Таково и старое, и современное положение дел. Отсюда автоматически вытекает, что знаменитая триада "наследование-инкапсуляция-полиморфизм" является извращением. Я называю его страуструповым, не интересуясь, он ли придумал это - как минимум, он это поддержал.

"Серверы" и "запросы" я подставил, чтобы его определение было более понятно (объект в такой системе очень напоминает вебсервер - ему можно послать любой запрос/сообщение, некоторые он обрабатывает, на некоторые даёт "ошибки 404").

Чтобы рассуждать и делать выводы, мне мандаты, сертификаты и государственные лицензии не требуются.

Главу я читал полностью, как вы могли видеть по приведенной мной ссылке на письмо в ньюсгруппу, но это было давно и издание было 6-е. Мне не так просто прямо сейчас найти 8-е.

Сама запись запросов в GemStone/S декларативна. Семантику _можно_ сделать декларативной (как уже сделано в GLORP и TOPLink - O/R frameworks для Smalltalks). Я примерно представляю, как это делать, но за реализацию не возьмусь из-за лицензионной политики фирмы Gemstone (или как она сейчас называется). Не забывайте, что декларативная запись SQL тоже в конечном счете ведет к вызову внутренних функций/процедур, циклам while и пр., которые сокрыты от SQL-программиста.

U-geneФигня! Вы не пробовали перед тем, как поставить, системную дату лет на 10 вперед перемотать...
Они "хитрые" (но мне кажется, что они перехитрили сами себя). Лицензия именная, это зашифрованный текстовый файл с явно заданной датой завершения в нем.

Андрей ЛеонидовичМне "надо было немного (или много) больше подумать над "головокружительными вариантами"" ???
Ну да ладно, ответ Вы, все-таки, дали. Не поддерживает GemStone ни связи многие-ко-многим (то есть поддерживает как и "Р"СУБД - нужно создать третий класс), ни семантику связей...
Особенно "элегантно":

1) "вполне очевидно раскладывается на связи"
в сочетании с
2) "там нет понятия "связей"".

Те связи, о которых шла речь, у нас в головах. В самом GemStone/S такого понятия нет. Чем вас не устраивает разбиение, о котором я сказал?

U-gene
ИМХО эта фишка с сообщениями позволяет сделать в определенном смысле совсем нетипизированную систему (в том смысле, что посылая сообщение объекту мы можем вообще не знать, что это за объект).

Да, Smalltalk и Self именно такие. Куда угодно может быть передано что угодно, послано какое угодно сообщение. А ещё у Self'а нет наследования.

vadiminfoТо что кто-то придумал что-то, то честь ему и хвала. И, наверное, он займет место в истории.

Разумеется, он занял место в истории, разве что вы её, по-видимому, не знаете. Возможно, для вас даже будет сюрпризом, что ОО, оконный интерфейс, мышь и сеть Ethernet появились в одном месте.

Но если он придумал стоящее, то оно должно развиваться. Так во многих областях. Кантор открыл теорию множества. Он гений. Но его теорию называю сегодня наивной. Однако главная идея и многие теориемы остались и сегодня.

Продолжение работ Кэя - это Squeak (http://www.squeak.org) и Open Croquet (http://opencroquet.org/). Он (вместе с группой товарищей) активно работает над ними.

То же объекты. Без "наследование-инкапсуляция-полиморфизм" что из себя предяставляют? Ведь именно это дает им возможность улучшенного моделирования по сравнению с другими подходами.
Возможность рационального проектирования.
Выкиньте это и объекты канут в лету.

Если объекты обмениваются сообщениями, а ничего кроме нет, то инкапсуляция и полиморфизм обеспечены автоматически. Наследование же не обязательно - существуют другие приемы.

Victor Metelitsa
"Серверы" и "запросы" я подставил, чтобы его определение было более понятно (объект в такой системе очень напоминает вебсервер - ему можно послать любой запрос/сообщение, некоторые он обрабатывает, на некоторые даёт "ошибки 404").

Это похоже на CОM. Но и в принципе терминами "обмен сообщениями" используют в ООП подходах. Это ничего не заменяет в тех "извращениях". Они главнее.

Согласен, что и на COM это похоже. Вообразите себе систему, где, кроме COM-объектов, ничего нет. Даже "числа" - COM-объекты.

Т.е., например, 1, 2 и 3 - это некие COM-объекты, запись 1 + 2 означает посылку сообщения с селектором + и аргументом-ссылкой на 2 объекту 1, и результатом сообщения будет ссылка на 3.

Victor Metelitsa
Чтобы рассуждать и делать выводы, мне мандаты, сертификаты и государственные лицензии не требуются.

Но чтобы делать громкие заявления, типа "Дейт ошибся" (или более сильные утверждения об авторитетах), они не лишни. Иначе может получиться не достаточно скромно.

В чём вы видите пользу "быть скромным"?

Victor Metelitsa
Не забывайте, что декларативная запись SQL тоже в конечном счете ведет к вызову внутренних функций/процедур, циклам while и пр., которые сокрыты от SQL-программиста.

Ну Вы еще вспомните, что все это выполняется в машинных командах. Потому нет разницы между С++ и ассемблером?
Имеет значение именно декларативность языка. SQL - язык БД.


В декларативном вы говорите "что", а в процедурном "как". Но Smalltalk вы можете трактовать и так, и сяк.

В GemStone/S нет связей в том же смысле, в каком нет складов, аэропортов и пр. Эти вещи моделируются объектами соответствующих классов. Если "связь" "сложная", имеет атрибуты, просто напрашивается сопоставить ей объект соответствующего класса.

В Self'е, кстати, не то что наследования - там и классов нет. Объекты размножаются копированием. Очевидно, каждый объект в подобной системе может (но не обязан) иметь уникальный набор методов.

vadiminfo
Если бы я все знал, то, наверное, мне не за чем было бы ходить на этот форум.

Форум - сомнительное место для приобретения знаний. Он полезен, чтобы понять, что что-то не знаешь, но за _знаниями_ лучше обращаться к руководствам, справочникам, учебникам, ...

Victor Metelitsa
Продолжение работ Кэя - это Squeak (http://www.squeak.org) и Open Croquet (http://opencroquet.org/). Он (вместе с группой товарищей) активно работает над ними.

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

Классная наработка - собачья пятая нога. Бывают, знаете ли, вещи, которые в лучшем случае ни к чему.

Victor Metelitsa
Если объекты обмениваются сообщениями, а ничего кроме нет, то инкапсуляция и полиморфизм обеспечены автоматически. Наследование же не обязательно - существуют другие приемы.

Инкапсуляция то не связана явно с наследованием. А вот такой тип полиморфизма как полиморфизм включения связан с наследованием.
Впрочем, наследование обосновано не тока этим, но и тем, что обобщение и специализация имеют значение в моделировании.

Есть другой подход - собирать всё из деталек. Агрегация. Человек - сборище клеток, которые состоят из молекул, которые состоят из атомов. Возьмем несколько человек, перетасуем их атомы и получим... жирафа.

Victor Metelitsa
Согласен, что и на COM это похоже. Вообразите себе систему, где, кроме COM-объектов, ничего нет. Даже "числа" - COM-объекты.

Т.е., например, 1, 2 и 3 - это некие COM-объекты, запись 1 + 2 означает посылку сообщения с селектором + и аргументом-ссылкой на 2 объекту 1, и результатом сообщения будет ссылка на 3.

И зачем такая система нужна? Все хорошо на своем месте. Чем 1, 2 и 3 - это некие COM-объекты, лучше, чем 1, 2 и 3 - это некие значения типа int?

Смысл в обобщении. Для написания универсального кода, которому всё равно, с чем он имеет дело. Некоему объекту посылается некое сообщение, он его как-то обрабатывает. Простейший пример:

ооо рисоватьСебяНаЭкране: экран.

Что есть ооо? Число, строка, иконка, экземпляр класса Авиакомпания, коллекция? Какая разница.

Ещё одна интересная черта ST - количество и код методов, переменные экземпляра, иерархия классов может меняться прямо во время выполнения программы.

Victor Metelitsa
В чём вы видите пользу "быть скромным"?

Ну, во всех отношениях. Начиная от Христианской этики, представлениями о хороших манерах в том же христианском мире, и кончая верой в то, что в профессиональном отношении скромность способствует повышению вероятности принятия правильных решений, более адекватному пониманию предмета, лучшему пониманию между коллегами.
Ну что это за интеллигент, если он не скромный? Чем же он отличается от подгулявшего купчика?
Я, конечно, не претендую сам (это было бы не скромно), но все-таки, надеюсь, что совсем далеко не захожу.

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

Victor Metelitsa
В декларативном вы говорите "что", а в процедурном "как". Но Smalltalk вы можете трактовать и так, и сяк.

Все-таки обыкновенно трактуют так или так. И раньше я думал, что Smalltalk т.е. не декларативный.

А тут имеет место двойственный случай. И выполнение одного и того же кода (!) может пойти по разному пути - исключительно цепочкой вызовов (характерно для процедурного подхода) или оптимизер с составлением и выполнением плана (как SQL).

Андрей ЛеонидовичЧто значит "просто напрашивается" ???
А что можно явно представить связь многие-ко-многим в GemStone ???
Не зацикливайтесь, Victor Metelitsa. Очевидно же, что:

1) в GemStone не поддерживаются связи многие-ко-многим (приходится, как и в "Р"СУБД, создавать еще один класс);
2) в GemStone не поддерживается семантика связей, просто потому, как Вы пояснили, что там "вообще нет связей" (на концептуальном уровне они есть - ER-модель, а на логическом - нет).

Я вас с трудом понимаю - если понимаю вообще.

(1)Что касается просто N:M (классы X и Y), то объект класса X может содержать/ссылаться на коллекцию Y, а объект класса Y - сдержать/ссылаться на коллекцию класса X, и, как понимаю, это и есть одна из реализаций связи многие-ко-многим между классом X и классом Y (в явном виде в GemStone/S не прописывается нигде).
(2)Если же (конкретные) связи имеют атрибуты, то связь (между объектами x и y) удобно представить как объект z (который знает про x и y, а x и y знают про z). (Слово "приходится" несёт негативный оттенок - вы знаете лучший вариант?)

Однако вы вольны держать в коллекциях объекты классов X и Y одновременно, и вот такую связь я вообще не знаю, как назвать. В GemStone/S можно задать constraint "эта коллекция содержит только экземпляры X", только это против духа Smalltalk'а, и потому я такие вещи не рассматриваю.