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


Тут то как раз никто не спорит. Объект существует в системе и только.
Но при тщательном анализе этого факта вырисовываются два подхода.
1. Объект ассоциируется с системным идентификатором(создаем идентификатор и вес жизненный цикл объекта присобачиваем к этому идентификатору). Это для внешних для системы объектов-прищелцев
2. Но есть внутреннние, родные для системы объекты. Допустим два объекта приписанных в системе вошли в отношение и получили свойства отношения. В таком случае этот объект-отношение можно однозначно идентифицировать порядком и идентификаторами вошедших в отношение объектов. Что вносит неоднозначность в систему идентификации. Но, этим самым мы добиваемся запрета создания отношений высшего порядка, а это, кажется, очень важно. (я выше говорил про формальную агрегацию понятий).

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

Этот подход привел к тому, что люди отделены от информации "железобетонной" стеной в виде (SQL)программистов и их кодов:)

На самом деле, результатом любого "запроса" является подсхема схемы БД СО ВСЕЙ ПРИСУЩЕЙ ЕЙ СЕМАНТИКОЙ. Для любителей алгебры не представляет никакого труда реализовать в объектной среде "технологию", подобную SQL для "произвольного связывания объектов" вне определенных связей (то есть, вне идентификаторов). Связывайте на здоровье, якобы для извлечения не познанных закономерностей:) И открытия новых законов природы:)

Вот пункт два меня мучает. Я даю возможность создавать отношения высших порядков Отношение{Отношение1,Отношение2,...}. Но скоко бы не думал, выше третьего порядка ничего осмысленного получить не могу, хотя формально строится пирамида понятий. :(
А если я убираю системный суррогатный идентификатор для отношения, то все семантичски возвращается в норму, но появляются проблема уточнение имен денормализованных свойств и предложения ставноятся все длинее и длинее :

ЗадеБред
В Ваших рассуждениях я бы обратил внимание на частично затронутый принципиальный аспект: Дейт считает, что аналогом класса ООП в РМД является домен, а не отношение:)

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

Дейт ничего не противопоставляет, а объясняет, таким образом, пути "оптимальной интеграции" объектных технологий (в смысле ООП) и РМД.

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


Тут то как раз никто не спорит. Объект существует в системе и только.
Но при тщательном анализе этого факта вырисовываются два подхода.
1. Объект ассоциируется с системным идентификатором(создаем идентификатор и вес жизненный цикл объекта присобачиваем к этому идентификатору). Это для внешних для системы объектов-прищелцев
2. Но есть внутреннние, родные для системы объекты. Допустим два объекта приписанных в системе вошли в отношение и получили свойства отношения. В таком случае этот объект-отношение можно однозначно идентифицировать порядком и идентификаторами вошедших в отношение объектов. Что вносит неоднозначность в систему идентификации. Но, этим самым мы добиваемся запрета создания отношений высшего порядка, а это, кажется, очень важно. (я выше говорил про формальную агрегацию понятий).

Вот пункт два меня мучает. Я даю возможность создавать отношения высших порядков Отношение{Отношение1,Отношение2,...}. Но скоко бы не думал, выше третьего порядка ничего осмысленного получить не могу, хотя формально строится пирамида понятий. :(
А если я убираю системный суррогатный идентификатор для отношения, то все семантичски возвращается в норму, но появляются проблема уточнение имен денормализованных свойств и предложения ставноятся все длинее и длинее :

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

Этот подход привел к тому, что люди отделены от информации "железобетонной" стеной в виде (SQL)программистов и их кодов:)

На самом деле, результатом любого "запроса" является подсхема схемы БД СО ВСЕЙ ПРИСУЩЕЙ ЕЙ СЕМАНТИКОЙ. Для любителей алгебры не представляет никакого труда реализовать в объектной среде "технологию", подобную SQL для "произвольного связывания объектов" вне определенных связей (то есть, вне идентификаторов). Связывайте на здоровье, якобы для извлечения не познанных закономерностей:) И открытия новых законов природы:)

ЗадеБред,

честно гворя мне пофиг кодд, дейт и их рмд, ооп и т.д.
СКЛ сервер я использую токо из за того, что никто не покупает проги для корпоратвного уровня, которые не базируются на скл серверах. Тенденции таковы.
вот и приходится на ск серверах моделировать свои фиговины.
А про то что задавая "семантику"в какой нить хранимой процедуре можно получить что угодно я давно знаю.
select "человек" as оборотень from ишак where "пофиг"="пофиг"

:) мне не пофиг, конечно... и именно поэтому я и работаю над тем, чтобы люди не покупали "проги для корпоративного уровня, которые базируются на скл серверах"... и их уже давно многие не покупают:) Однако см. мое примечание о том, что никто не мешает .... и т.д.

_модБред- из-за отсутствия регистрации упомянутых событий в нашей прикладной системе.
из-за отсутствия необходимости регистрации упомянутых событий в нашей прикладной системе.

Можно и так. Результат тот же:)

_мод[quot Бред]
Это и есть принципиальная ошибка:) У Вас здесь принципиально нет связей.
Ессно нет. Есть типы данных - типы объектов.
Бред

Именно. Но мне показалось, что мы говорили не о парадигмах программирования (например, ООП). Видимо, померещилось:) Значит связей просто нет. И на вопрос в названии темы можно уверенно ответить: "Они совершенно не нужны":)
И хорошо...
Забыл, что мы на sql.ru ::

_модБредЗначит связей просто нет.
Это я поспешил, извините. Если свойство объекта имеет тип объекта и СУБД об этом знает, то связь между этими объектами существует и ее можно использовать например для навигации.
Но если СУБД не поддерживает типы объектов, то и связи не будет.

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

_мод,

Давно обосновал. До реализации. Иначе, как же можно было реализовать?:)
И здесь обосновал. Весьма основательно:)
Посмотрите, по-внимательнее, на дом, в котором Вы живете. Неужели Вы являетесь его свойством???:)
А теперь посмотрите на себя. Неужели Вашим свойством является дом???:)
Так зачем же все усложнять???

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

LSVIvan DurakCerber-88,
А еще в чужой базе без связей разобраться труднова-то.....И особенно сложно разобраться, когда связей(констрайнтов) нет. Пример - практически любая КИС или ERP.

"Практически любые КИС или ERP" без связей - это не КИС и не ERP. Они создаются с одной целью - борьба с безработицей среди программистов:)

_модБредПосмотрите, по-внимательнее, на дом, в котором Вы живете. Неужели Вы являетесь его свойством???:)А теперь посмотрите на себя. Неужели Вашим свойством является дом???:)
Это и есть обоснование ?
Все зависит от выбранной модели. Если отдельные дома являются объектами (как в ПИБ), то ссылки на них будут св-вами объектов Граждане, Организации и пр.
Бред
В действительности, со связями уже давно все понятно.
Видимо не для всех и не до конца.
Бред
А вот подумать о типизации объектов полезно. А именно, ввести два типа: сущность и событие
Это всего лишь условность, полезная при проектировании систем определенного класса, например учетных. Давно и широко используется.

1) Вчитайтесь в Ваше обоснование после игнорирования простого (физического:)) взгляда на дом: "Если отдельные [а какие же еще?] дома являются объектами [пока нормально, но только экземплярами объекта Дом, но это, в данном контексте, не принципиально - пусть объектами класса Дом], то ссылки на них будут свойствами Граждан" ??? Для Вас это так, потому что Вы ВЫБРАЛИ модель (ООП) безо всякого обоснования! У Вас просто НЕТ ВЫБОРА: что в РМД, что в ОРМД, что в ООП Вы просто ВЫНУЖДЕНЫ считать Дом Вашим свойством. Игнорируя действительность, и не получая при этом ничего, кроме головной боли, по сравнению с обычной объектной моделью Гражданин - Проживает в - Дом. Что и есть на самом деле:) Гражданин действительно проживает в доме:)
2) Да, конечно, не для всех и не до конца. Я только про себя:)
3) А здесь ("давно и широко") Вы не про модели данных говорите. А о том, что приходится делать вопреки. Так что на том уровне, который мы обсуждаем, пока никак и нигде не используется. И не известно когда будет использоваться.

_модБредДля Вас это так, потому что Вы ВЫБРАЛИ модель (ООП) безо всякого обоснования!

А это всегда так - выбирается модель, отвечающая задаче. Никакого обоснования не требуется.
В одной модели дом - это объект (экзепляр класса) и на него есть ссылки, а в другой модели такого объекта просто нет, а есть номер дома в поле адрес. Все зависит от выбора проектировщика (а выбор всегда есть).
БредТак что на том уровне, который мы обсуждаем, пока никак и нигде не используется. И не известно когда будет использоваться.
Ну я использую, и давно.

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

Нет не используете:) У Вас просто нет такой СУБД и такой МД. Вы вынуждены все реализовывать на уровне приложения. Но это, конечно, гипотеза. Основанная на Ваших сообщениях. Из которых следует, что у Вас дом является Вашим свойством:)

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

Скатываемся в убогое состояние по следующей логической цепочке:
Зачем связи, вполне можно обойтись ссылками.
Зачем ссылки, вполне можно обойтись внешними ключами.
Зачем внешние ключи, вполне можно слепить чего-нибудь на уровне приложения (как в "передовых" КИС и ERP)

Все, значит, хорошо. Ну и ладненько:)