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

ViPRosСамая подлая вещь в СКЛ - конструкция FROM. Типизированные Связи и Роли в Отношениях позволяют FROM перевести в разряд опциональных хинтов.
Результатом запроса к БД должна быть подсхема схемы БД со всей присущей БД семантикой, а не какое-то бессмысленное "отношение", с которым работают "математики" (а не пользователи).
Так что, например, для схемы БД из двуз объектов, связанных М:М

Человек (A) <-- Работает в/В которой работает (1) -->Организация (B)

запрос к этой схеме должен иметь примерно такую FROM:

FROM A-1-B

(где A и B - идентификаторы объектов, 1 - номер связи).

ViPRosБредятина,

нет. From должен присутствовать только для улучшения производительности.
А запрос должен имет семантику типа ТипСвязи1(А (или*) в Роли1 , B (или *) в Роли2)

Тут ТипСвязи1 = Работает.
Роль1 = Работник
Роль2 = Огранизация

ТИпСвязи! могла бы классифицировать N связей и мы бы обошлись без явного перечисления UNION и приведения атрибутов (если бы Атрибуты были типизированы).

FROM Требует знания логической структуры.
Иммутбельность тут не причем.
Тоже нет:)
Я объясняю азы классической объектной модели данных, и использовал FROM для преемственности и понимания теми, кто знаком с FROM, только и всего.
Никакого отношения к производительности FROM не имеет.

Результатом запроса должна быть таже схема
Человек (A) <-- Работает в/В которой работает (1) -->Организация (B)
с, возможно меньшим количеством экземпляров объектов Человек (именно, Человек, а не Работник:)) и Организация, чем количество экземпляров в БД.

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

Хотя правильнее было бы, конечно, вернуться к теме, так как реализация классификатора, как типа характеристики (наборы-то давно реализованы) - это, дествительно, важное неправление:)

ViPRosViPRos,

Никаких FROM
Так их, проклятых!

Например:

FOR подсхема данных
SELECT ...

Никаких FROM:)

ViPRosНе надо КАК, не надо ОТКУДА
Только ЧТО
Ну, хорошо:)

[quot guest_20040621]> азы классической объектной модели данных

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

Модератор:

aikusНемного про сет енум, я их когда то применял по двум причинам:
1. было лень или некогда писать отдельную табличку.
2. наивно думал, что данного набора хватит.
теперь про недостатки: 1 причина убога в корне, 2 - на самом деле очень часто приходилось добавлять значения, а т.к. эти значения добавляются не прозрачно, то возникают опасность появления ошибок.

Вы просто, пока, не поняли до конца о чем речь, но это нормально.
1 - это у вас бесполезный субъективный аргумент; супертип "набор" (кодов, строк, чисел) часто используется, и, очень часто, наиболее удобен;
2 - значения в набор постоянно добавляются, а не очень часто.
aikusТеперь немного про бредятину:
Сразу признаюсь, что я ни чего не понимаю из описанного вами.

Это я понял, не Вы один:) Но Вы и вопросов никаких не задаете. Я то все это понял тридцать лет назад, и мне довольно трудно понять, как можно не понимать такие очевидные вещи:)
aikus1. То что вы описываете в примере человек <-> работа в принципе укладывается в обыкновенный триплет, а таких баз в своё время натворили уже достаточно.

Это просто подтверждает, что Вы ничего не поняли:) Но это не беда.
aikus2. Вероятно вам что-то даст neo4j
:)

Модератор: граждане Бредятина и guest_20040621 , если вам есть что рассказать друг другу, высказывайтесь по существу

Роман ДынникБредятина,
По-моему, проблема в том, что вы свои мысли не можете чётко формализовать, по-этому их ход никто не понимает.

А по-моему, все уже давно отвыкля понимать формализованные мысли:)
Скажите, четко что именно Вы не поняли, тем более, что ничего нового я не говорю.
Роман ДынникЕсть реляционные БД, объектные, сетевые. Вы о чем вообще пишете? О чем то своем?
Формализуйте хотя бы тему, тогда может вынесем ее в отдельную ветку для обсуждения.

Немного не точно. Есть записе-ориентированные (например, "реляционные", в которых отсутствуют идентификаторы экземпляров объекта, но есть ограничения целостности в виде "ключей", которые находятся среди прочих характеристик объекта) и объектно-ориентированные (в которых, идентификаторы экземпляров есть, и находятся вне характеристик экземпляра объекта). Не нужно ничего выносить, так как это здесь никого не интересует. Поэтоу я Вам и предложил вернуться к "наборам" и "классификаторам". Впочем это тоже вряд ли кого интересует:)
Роман Дынник...Приведите пример (кусок диаграммы), что вы понимаете под концептуальной моделью без связей?
Это еще что такое "концептуальная модель без связей"???

guest_20040621> азы классической объектной модели данных

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

Ник - со смыслом. Редкостный бред.

То есть, уважаемый модератор с этим согласен? Мне забыли что-то рассказать, и я говорю редкостный бред?
Ну что же я это учту, конечно:)
Модератор: это личное мнение автора по теме

Роман ДынникЯ об этом:
БредятинаА цель предельно проста - свести к минимуму программирование приложений за счет "соединения" концептуальной модели и логической.
Вы можете привести пример концептуальной или логической модели без связей?

Вы не понимаете сути вопроса, к сожалению. Где Вы видите в моей фразе о том, что концептуальная модель должна стать логической, хоть слово о "связях"???
Если уж Вы говорите о связях, в концептуальной модели связи есть, а в логической - нет. Но, поскольку Вы не понимаете даже абсолютно ясное определение связи, то, конечно, путаетесь с концептуальной, логической, связями...
Роман ДынникВы хорошо понимаете разницу между концептуальной моделью И логической и для чего они нужны?
Безусловно, я понимаю не просто хорошо, а, к великому сожалению, очень хорошо:)
И, конечно, в результате, то, что я говорю - это редкостный бред:)

ViPRosРоман Дынник,

я воще то думал что Бредятина злится на Отсутствие связей в РСУБД :)
:) злится - это сильно сказано... связи отсутсвуют во всех известных ЛОГИЧЕСКИХ моделях данных, кроме классической объектной модели данных, которая является и концептуальной, и логической, и позволяет создавать приложения с минимальным программированием