doublefintБред, согласитесь, Cache все-таки шаг вперед. Возможно маленький с точки зрения "правильных" теорий, но вперед. Или Вы хотите послушать, что говорят те самые конечные пользователи (ради которых все и делается) по поводу объектного навигатора?
Бред"Р"СУБД и были созданы для того, чтобы дать работу массе программистов О как... Надеюсь, Вы это несерьезно?

То есть, вы задумались над проблемой? Это хорошо:) Когда Вы говорите "вперед", вы имеете в ввиду реализацию парадигмы ООП в среде mumps? Да, вперед. В том смысле, что было процедурное программирование, структурное программирование, декларативное и т.п., а теперь стало еще и объектно-ориентированное:)
Но разве мы об этом говорим в этой теме???
А вы хотите послушать что говорят "конечные пользователи" про ООП и программирование запросов на SQL?:)
Я ни слова не сказал ни про какой "объектный навигатор". И уже привых, что на sql.ru невозможно обсуждать вопросы по существу:)

Alexey Maslovdoublefintэтим нельзя пользоваться?Именно. Представьте, что это авторы-книги. У 1 автора м.б. несколько книг. У 1 книги - несколько авторов. Пока все хорошо :) Но вот вы решили удалить из БД книгу (ошибочно введенную, например, да мало ли по какой причине). Как вы это сделаете? Не удалив всех ее авторов, вы книгу не удалите.
Введя промежуточный объект (e.g. "авторство"), связанный с книгой и с автором отношениями 1:M, мы эту проблему снимаем. Если продолжать использовать Relationship, то удаление книги потребует предварительного удаление всех дочерних "авторств" - но не авторов.
Сторонники "чисто объектного" подхода хотели бы, чтобы связь выступала как отдельная сущность (хотя и нехорошо так ее называть :), которая может иметь атрибуты и т.д. Но мне кажется, что это не принципиально - нагрузить атрибутами промежуточный объект (таблицу), или саму связь.

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

Человек --- Имеет/Принадлежит ---> Авторство
Авторство <--- Относится к/Имеет --- Книга

Но может быть, в зависимости от уровня абстракции, и два объекта и одна связь:

Человек <--- Является автором/Автором которой является ---> Книга

Очевидно, что экземпляр объекта Книга элементарно удаляется, и это, конечно, не требует удаления экземпляров объекта Человек:) Здесь я, конечно, не имею в виду кривую реализацию в Cache. Так вот, в Вашем случае, если я правильно понял уровень абстракции, более удобен и лаконичен как раз второй вариант.

И что-либо здесь программировать в 21-м веке это просто издевательство над здравым смыслом (это я для doublefint:)).

krvsa2acidреализация "авторы - книги" не подойдет ?
Для практического применения - нет.
Ошибочное утверждение:)

krvsaAlexey MaslovНо вот вы решили удалить из БД книгу ...
Или книга вышла в новой редакции и там авторство поменялось... А книга-то та же.
Да мало ли чего еще! Там только ткнись в предметную облать - весь такой макет затрещит по швам...

Нет. Не конкретные рассуждения.
Если книга "вышла в другой редакции" или "авторство поменялось" - это однозначно другой экземпляр объекта Книга в принятой упрощенной модели. И схема "два объекта и одна связь" продолжает прекрасно работать:)

krvsaБред"конечные пользователи"
Это кто? Юзеры? Те, кто в, писаных нами программках, работает?

БредИ уже привых, что на sql.ru невозможно обсуждать вопросы по существу:)
Ну вот... Уже и форум не такой...

Спросите у автора сообщения о "конечных пользователях":)
Сделайте форум "таким":)

krvsaБредОшибочное утверждение:)
Таки и примера практического от тебя тоже не видел еще...

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

krvsaБредСделайте форум "таким":)
"Таким" что бы он нравился тебе?
Мы этого не сможем по определению...

Вы мне предлагаете не мешать обсуждать "проблемы программирования"?:)
Опять помешал:)...

krvsaБредВы мне предлагаете не мешать обсуждать "проблемы программирования"?:)
Опять помешал:)...
Делай чего хочешь... Кто тебе мешает?

Спасибо:) Но Вы опять о чем-то о своем:) Мне бы не хотелось Вам мешать... Своим бредом:)

krvsaБредЯ Вам говорю, что Вы ошибаетесь, называя этот пример "не практическим".
Поверю если ты сделаешь хоть одну практическую задачку использую такую "связь"...

Какую связь??? М:М, вообще???
Мы рассматривали конкретный пример. И я четко показал, что, в зависимости от постановки задачи этот пример прекрасно работает. Например, задача заключается лишь в том, чтобы получать информацию: кто из людей какую книгу "написал".
Если Вас серьезно интересует этот вопрос, то вкратце сообщу.
Очень часто связи М:М (как, впрочем, и связи с другой мощностью) используются в процессе ДЕНОРМАЛИЗАЦИИ данных. В процессе денормализации Вы можете создавать как избыточные характеристики объектов, так и избыточные связи. И в том, и в другом случае Вы добиваетесь производимтельности и/или удобства отображения, ценой усложнения транзакций и поддержки целостности. В частности, представьте себе, что мы спректировали бы наш пример (описание "авторства" книг) "по полной программе". И там было бы (в нормализованном виде) пять объектов и пять связей. И среди них не было бы прямой связи Человека с Книгой. Однако, вполне может возникнуть потребность в поддержке такой связи для выволнения соответсвующего (весьма востребованного) сервиса.
Извините, еще раз, за беспокойство:)

doublefintБред, согласен, замечание было некорректным. Прошу прощения. Вам повезло с пользователями, раз они готовы оперировать понятиями "Объект" и "Связи"
Извините, но мы ничего не говорили о реализации пользовательских интерфейсов. И слов в них:)
Я бы предпочел обсуждать только ту "проблему", которая поставлена в теме:)

doublefintkrvsa Поверю если ты сделаешь хоть одну практическую задачку использую такую "связь"... Лично у меня может сил и не хватить (пишите тз ;), но я знаю как минимум одну систему (система управления предприятием) на Cache, использующую "объектную" модель. Конечно, есть много всяких "но"... Например, в ней используется только прямой доступ (Cache как среда выполнения М-кода и никаких Relationship), и "связь" между "объектами" имеет свойства... Но в остальном мне идея очень, очень понравилась.
БредИ что-либо здесь программировать в 21-м веке это просто издевательство над здравым смыслом Можно что-нибудь в виде ссылок на используемое ПО?

Мы обсуждаем концептуальный вопрос. Связанный с моделированием данных. И, следовательно, с моделями данных. Я действительно занимаюсь этим вопросом более 25 лет. И, конечно, на том или ином этапе этой деятельности участвую в каких-то реализациях:) Вот и сейчас участвую. Но сейчас не в Cache (о чем сожалею, так как mumps остается единственной относительно полноценной технологией создания СУБД):) Сейчас для меня все абсолютно ясно со связями. Значительно интереснее проблема типизации объектов. Кодд, как я уже сообщал здесь много раз, пытался типизировать отношения на "отношение типа сущности" и "отношения типа связи", но на уровне МД это не получилось из-за проблем с алгеброй. Когда же мы отделили объекты от связей, и разобрались со связями, можно подумать о типизации объектов. Представляет интерес опять же ДВА типа: сущность и событие (участниками которых являются сущности).
На этом форуме я неоднократно слышал: "так что здесь нового, мы уже сто лет так и делаем".
Да, но это делается на уровне приложения. Много чего можно сделать на уровне приложения. Я же говорю о МД и соответствующей СУБД....
Извините, что ушел от ответа и не дал ссылок:) Я считаю, что Вы должны знать все, что делалось в этой области, ну хотя бы в среде mumps, раз Вы в ней работаете:)
Суть проста: стереть грань между концптуальным и логическим проектированием в одном инструменте. Чтобы не заниматься "мэппигами" бесконечными. И программированием, оправданным только борьбой с безработицей:)

DAiMorПО в разработке которого я принимаю участие, что-то типа 1С, а соответственно много вещей где нужны связи между таблицами
к примеру такие как шапка документа и строки документа
ну в основном все ограничивается связями один-ко-многим
классов очень много во всем приложении
каждый документ отдельный класс, строки к нему еще класс, а разных зависимых таблиц к документу может быть несколько
и во всем приложении нету ни одного RelationShip
приложение думаю не сильно от этого страдает
все классы наследуются от одного базового класса в котором прописаны некоторые базовые поля и параметры, обязательные для всех классов в системе
так вот для организации связи между строками документа с его "шапкой", используется свойство ExtParent, в котором хранится ID шапки документа, в классе со строками описан параметр ExtParentClass в котором прописан класс "шапки документа"
и вся логика приложения построена на связи этих полей, в наборе компонентов которые используются в клиентском приложении, используются такие связи, и собственно при создании нового документа нужно только создать классы добавить форму в клиентском приложении и все готово

конечно когда необходимо sql запросом получить данные из таких классов приходится использовать JOIN
_________________________________
Cache for Windows NT (AMD64) 5.0.21 (Build 6408) Tue Jan 3 2006 13:37:41 EST

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

kolesovБредЯ Вам говорю, что Вы ошибаетесь, называя этот пример "не практическим". А вы, не обращая на это внимания, говорите о чем-то о своем, предполагая, к тому же, мою неспособность приводить примеры:)
Что после этого означает Ваша фраза "ну вот, и форум не нравится"?:)

Где-то я уже этот пример видел ;) Причем интонации "докладчика" были примерно такими же. Почти уверен, что это Вы и были...
Знаете анекдот про французскую болонку и кобеля-дворянина, который "просто пос*ать вышел"?

У меня:
- пользователи, за редким и приятным исключением, не понимают вообще, "как это работает". Они выучивают последовательность нажатий кнопок. Есть одно рабочее место, где я уже 2 года отказываюсь добавить единственную(!) на интерфейсе кнопку "Подтверждаю", потому, что если ее добавить, ответственность возьмет на себя человек, который в принципе отвечать ни за что не должен/не может. И если на экране что-то не так, должен просто сообщить "старшему", у которого есть кнопка "Отменить". Они не тупые. Это просто не их жизнь.
- заказчики, которым система очень нужна, но им абсолютно фиолетово, как она устроена, и как действует. Главное, чтобы работала. Кстати, если в Вашей системе есть сильные отчеты, поинтересуйтесь, сколько раз их использовал директорат - у нас это число стремится к нулю. Реально отчетами занимаются 2-3 человека, которые просто любят и умеют работать с отчетностью. И по запросам руководства их регулярно изготовляют. Заказчики очень умные. В своем бизнесе.
- бизнес, который запутан так, что честный интегратор (ах, если бы такие были на свете) или отказался или встрял и повесился через пару месяцев, а нечестный поднял бы бабла и только ;) Сколько -зависит исключительно от способности правильно инициировать переменные во фразе "ну... теперь-то я могу с уверенностью утверждать, что мы получим результат х к сроку у", причем "х" должен стремиться к нулю, а "у" к бесконечности как можно медленнее... в другие-то стороны они у интеграторов стремиться не умеют в принципе. Бизнес серьезный, он проще быть не умеет.

... да, чуть не забыл... про моделирование:

Мне бы Ваши проблемы. У меня основная работа:
- найти, чем можно пренебречь (Проектирование отношений в сравнении с этим - отдых на Пхукете)
- успеть поймать за руку программиста, когда он пытается добавить ненужную в системе сущность (вернее сущность, академически и паттерново красивую, но нахрен никому не нужную);
- вычищать из системы лишнее (то, что по каким-то причинам не успел...)
- бороться с производительностью (вот тут кайф и наступает...)

Сущность ли связь... не сущность ли связь... науке это неизвестно. Ну, да мы, благо, и не "от науки", а так, попрограммировать вышли ;)

Хороший пример моделирования связей между сущностями:)
А уж про программистов, которые по собственной инициативе "добавляют в систему ненужные сущности", просто дух захватывает... И с кнопками проблемы... Извините, что только отвлекаю Вас от важных дел своими глупостями:)

antares0
А можно все же несколько сыылок и keyword-ов для расширения кругозора, не работающих в обсласти mumps?
Очень заинтересовало.
А среди "не работающего в области mumps" ничего стоящего, тем более, пока не наблюдается. В области "коммерческих" МД и СУБД уже 30 лет продолжается период стагнации с периодическими шараханьями в сторону модных течений, не приближающих, однако, людей к данным:) К тому же, прибавилась еще одна сложная проблема - плохая совместимость технологий БД и интернета. В вебе, например, еще больше проблем с реализацией эффективного и управляемого пользователями интерфейса, о которых частично говорилось выше. Есть определенные надежды на реализацию в этом году, тем не менее:)