Leonid KudryavtsevДмитрий, я надеюсь Вы шутите и не предлагаете номер телефона делать Primary Key?
Если же таблица телефонов(или контактов) работает исключительно по суррогатному ключу, то никаких "много ко многим" не будет, даже если курить качественные психоактивные вещества.



Это как? Один и тот же телефон, но с разными суррогатами? И если в номере ошибка править в нескольких местах? И чтобы сложней было сразу увидеть, что у одного телефона несколько челов? Или что?

krvsavadiminfoОдин и тот же телефон, но с разными суррогатами? И если в номере ошибка править в нескольких местах? И чтобы сложней было сразу увидеть, что у одного телефона несколько челов? Или что?
Такими темпами у тебя появится таблица "Смена номера", ведь номер могут и поменять!
Не смог связать Ваш ответ с цитатой никак.
Я никаких таблиц не предлагал, а спрашивал о том как суррогаты отменят многие ко многим, если у чела много телефонов и один телефон у многих, если что.

Leonid KudryavtsevЖесть

Вообще то это был вопрос.
Хотелось бы на него ответ получить. Все таки Ваше утверждение выглядит типа "не по учебникам", так как до сих пор суррогаты не претендовали на то, чтобы "то никаких "много ко многим" не будет", если оные есть в ПО (раз "номер телефона делать Primary Key" и они будут).

Leonid KudryavtsevА нафига это видеть?

Ну раз она есть в ПО, а мы оную моделируем в БД, то для того чтобы МД как бы лучше ответствовала этой самой ПО.
Это упростит понимание ифны в БД.

Leonid KudryavtsevLeonid KudryavtsevОдин и тот же телефон, но с разными суррогатами?
Да, конечно.

Введение полноценной БД телефонов (номеров) при котором может появится связь многое-ко-многим усложняет задачу на порядок. И для разработчика и для пользователя(!). Не давая взамен никакой новой осмысленной дополнительной функциональности.

Вот так бы и сразу.

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

Leonid KudryavtsevДа, только так и никак иначе.

В ощем случае, скорее всего, иначе: менять в одном месте. Вы есче нормальные формы отмените: они тоже в том числе чтобы было иначе.

Leonid KudryavtsevНе читайте книжек Гради Буча перед едой или сном )))
/Тут смайлик!/

Ну поскольку речь шла о книжках по БД, то получается их тоже не читать. Кого же читать? Неужели предложите заменить их Вашими текстами на форуме?

Leonid Kudryavtsev1. Что такое ОЦ?


Читайте книжки по БД. Это ограничения целостности - логические правила которым должены отвечть данные. Например, ОЦ уникальность на телефоны не позволит один и тот же телефон заносить дважды.

Leonid Kudryavtsev2. ведь БД предполагать повторы номеров - с чего это?

С того что нет выше указанного ОЦ. Значит юзер может одному и тому челу допускается набить один и тот же телефон много раз.

Leonid Kudryavtsev3. А поскольку будут опечатки - опечатки есть всегда, проблемы не вижу.

Проблема в том что это на самом деле должен был быть один у нескольких, а теперь разные. Соотвественно, обнаружив что нет нужного юзер вместо исправления добавить правильный. Т.е. контроль опечаток имеет потенциал усложнения.

Leonid KudryavtsevЕсть человек, есть номер телефона/ов которыми он пользуется. Если у человека изменился номер телефона (например он сменил квартиру, снял другую комнату), менять нужно в ОДНОМ месте. В карточке ДАННОГО человека.
Изменился номер в комуналке, или другой какой общий.

Кроме того, суррогаты здесь все равно ни при чем: у Вас просто несколько "искаженая" МД. Оно может быть как с суррогатами так и с естественными. С друой стороны для многие ко многим суррогаты юзаются.

krvsa vadiminfo , где твой пример структуры?
А причем здесь какой-то мой пример структуры? Хотите сказать что структура для многие ко многим не известна? Или что?

krvsaДействительно! Зачем она?!
Ведь тогда все прекратиться.

Ну вот типа в ветке привели, и не прекратилось все. А даже наоборот.


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


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

Тут чел изобрел метод с помощью суррогатов от многие ко многим избавляться. Это поинтереснее структур в этой ветке.

krvsa vadiminfo , от тебя будет пример структуры? Да или нет?
Не вижу связи вопроса с моими текстами. Никаких причин прводить какие-то структуры из "дискусии" в которой участвую вроде не было. Там все очевидно и так, вроде.

Leonid KudryavtsevVadiminfo, Вы хоть одну реальную учетную систему видели?

Вообще-то речь шла не о реальных учетных системах, а о Вашем утверждении, что никих "многие ко многим" не будет, если суррогаты... Хотя они (многоие ко многим) есть, в предположаниях о предметной области Dmitry V. Liseev.


Leonid KudryavtsevСуррогаты тут при том, что номер телефона здесь совершенно НЕ при чем. Т.к. есть клиент (в задаче топикастера пользователь), если способы с ним связаться. Телефон - один из многих способов. Просто текстовое поле с буковками и цифирьками. Возможно с какими-то базовыми проверками (что бы полную чушь туда не вбивали).

Где здесь? И в каком смыле причем и не причем номер телефона? Вполне "многие ко многим" можно и суррогатом организовать.
С дргой стороны, в Вашей схеме суррогат заменяет естесвеный идентификатор пользователя, а не телефон, насколько я понял.


Leonid KudryavtsevПовторюсь: связи многое ко многим в данной задачи взяться вообще НЕ откуда.

А она таки "взялась" таки благодаря Dmitry V. Liseev. Т.е. один телефон может быть у многих. И у одного много телефонов - это означает, что многие ко многим "взялась".

Leonid KudryavtsevЕсли Вы знаете системы, где для такой задачи сделали связь N:N, тогда сразу приводите конкретную ссылку.

Речь шла не о "такой" или "не такой" задаче. А вообще об отмене суррогатом связи многие ко многим в принципе.

На практике, если телефоны второсортная инфа, то исажение МД, ради упрощения приложения в целом исключать нельзя.
Оптимизация приложения в целом может допускать деоптимизацию отдельных ее частей, например БД.



Leonid KudryavtsevЖдем пример рабочей структуры N:N для задачи
Не зависмо от задачи структуры для многие ко многим подобны. В том числе и суррогатами:
ЧЕЛ{ИД_ЧЕЛ, ....}; ТЕЛ{ИД_ТЕЛ,....}; ЧЕЛ_ТЕЛ{ИД_ЧЕЛ,ИД_ТЕЛ} - это для всязи многие ко многим

Это вроде все достаточно избито. Так что не понял, что тут можно ждать.

krvsaСлив защитан...
Угу. Вам только сливы защитывать.

Leonid KudryavtsevС дискуссии сливаюсь, ....
Ну стало быть применение суррогатов для того чтобы "много ко многим не было" как бы можно тогда пока отложить.
Пока тогда можно по старинке, по толстым книжкам по БД.