Этот вопрос показывает, что вы не до конца понимаете отношения сущностей (без грубости).Из них есть четыре (технически только 3) типа ниже:
One to One
One to Many
Many to One
Many to Many
Один к одному (1: 1): В этом случае таблица была разбита на две части дляв целях соответствия нормализации или, чаще, принципу открытого закрытого доступа.
Нормализация соответствие: у вас может быть бизнес-правило, согласно которому у каждого клиента есть только одна учетная запись.Технически, в этом случае можно сказать, что клиент и учетная запись могут быть в одной таблице, но это нарушает правила нормализации, поэтому вы разделяете их и делаете 1: 1.
Open-CloseПринцип соответствие: таблица клиента, может иметь идентификатор, имя и фамилию и адрес.Позже кто-то решает добавить дату рождения и вместе с ней возможность рассчитать возраст вместе с кучей других столь необходимых полей.Это слишком упрощенный пример «один к одному», но вы получаете основное использование для его расширения базы данных без нарушения существующего кода.Большая часть написанного кода (к сожалению) тесно связана с базой данных, поэтому изменения в структуре таблицы повредят код.Подобное добавление 1: 1 расширит таблицу для соответствия новым требованиям без изменения исходного кода, что позволит старому коду продолжать нормально функционировать и новому коду использовать новые функции БД.
Недостаток нормализациии расширение таблиц, используя отношения 1: 1 таким образом, является производительностью.Часто в интенсивно используемых системах первой целью повышения производительности базы данных является нормализация и объединение таких таблиц в одну таблицу и оптимизация индексов, что устраняет необходимость использования объединений и чтения из нескольких таблиц.Нормализация / Денормализация не является ни хорошей, ни плохой вещью, поскольку она зависит от потребностей системы.Большинство систем обычно начинают с нормализованного перехода обратно, когда это необходимо, но это изменение должно быть сделано очень осторожно, как уже упоминалось, если код тесно связан со структурой БД, это почти наверняка приведет к сбою системы.т.е. когда вы объединяете 2 таблицы, одна перестает существовать, весь код, который включает в себя эту теперь несуществующую таблицу, завершается сбоем до тех пор, пока она не будет изменена (в терминах БД представьте себе, как соединять отношения с любой из таблиц в 1: 1 при удалении этих таблицэто нарушает отношения, и поэтому структура должна быть значительно изменена, чтобы компенсировать это. К сожалению, такие плохие проекты гораздо легче обнаружить в мире БД, чем в мире программного обеспечения в большинстве случаев, и вы обычно не замечаете, что что-то пошло не такв коде, пока все не развалится), если система не спроектирована должным образом с учетом разделения интересов .
Это наиболее близкая вещь, которую вы можете получить к наследованию в объектно-ориентированном программировании.Но это не совсем то же самое.
Один ко многим (1: M) / Много к одному (M: 1): Эти два отношения (следовательно, 4 становятся 3), являютсяСамые популярные типы отношений.Они оба относятся к одному типу отношений, единственное, что меняется, это ваша точка зрения.Пример. У клиента много телефонных номеров, или, альтернативно, много телефонных номеров могут принадлежать клиенту.
В объектно-ориентированном программировании это считается композицией.Это не наследство, но вы говорите, что один элемент состоит из многих частей.Обычно это представляется массивами / списками / коллекциями и т. Д. Внутри классов, в отличие от структуры наследования.
От многих ко многим (М: М): ЭтоТип отношений с современными технологиями невозможен.По этой причине нам нужно разбить его на два отношения «один ко многим», к которым присоединится таблица «ассоциации».Многоликая сторона отношений «один ко многим» всегда находится в таблице связей / связей.
Для вашего примера, человек, который сказал, что вам нужно много ко многим, является правильным. Потому что отношения «два ко многим» - это, по сути, отношения между многими (то есть более одного). Это единственный способ заставить вашу систему работать. Если вы не собираетесь исследовать область реляционного исчисления , чтобы найти какой-то новый тип отношений, который позволил бы это.
Кроме того, для таких отношений (м2м) у вас есть два варианта: либо создать составной ключ в таблице компоновщика, чтобы комбинация полей стала уникальной записью (если вы заинтересованы в оптимизации БД, это медленный выбор, но он занимает меньше времени) пространство). Кроме того, вы создаете третье поле с автоматически генерируемым столбцом идентификатора и делаете его первичным ключом (для оптимизации БД это более быстрый выбор, но занимает больше места).
В вашем примере конкретно выше ...
Примером из реальной жизни могут быть телефонные номера, пользователи и компании. У компании может быть много телефонных номеров, у пользователя может быть много телефонных номеров, но в идеале пользователь не должен указывать тот же номер телефона, что и у компании, поскольку в БД будет дублированный контент.
Это может быть отношение многих ко многим с таблицей телефонных номеров в качестве таблицы связей между компаниями и пользователями. Как уже говорилось, чтобы не повторять номер телефона, просто установите его в качестве первичного ключа или используйте другой первичный ключ и установите для поля номера телефона уникальный номер.
Для таких вопросов все зависит от того, как вы их сформулируете. Что вызывает у вас замешательство по этому поводу, и как вы преодолеете это замешательство, чтобы увидеть решение, просто. Перефразировать проблему следующим образом. Начните с вопроса «один на один», если ответ «нет», двигайтесь дальше. Следующий вопрос: «Один ко многим», если нет ответа. Единственный оставшийся вариант - это много ко многим. Будьте осторожны, убедитесь, что вы тщательно рассмотрели первые 2 вопроса, прежде чем двигаться дальше. Многие неопытные люди, работающие с базами данных, часто слишком усложняют проблемы, определяя один ко многим, как много ко многим. Еще раз, самый популярный тип отношений на сегодняшний день - это один ко многим (я бы сказал, 90%), причем многие ко многим и один к одному делят оставшиеся 10% 7/3 соответственно. Но эти цифры - только моя личная точка зрения, поэтому не приводите их в качестве стандартной статистики. Моя точка зрения заключается в том, чтобы сделать дополнительную дополнительную уверенность, что это определенно не один для многих, прежде чем выбирать много для многих. Это стоит дополнительных усилий.
Итак, теперь, чтобы найти таблицу компоновщиков между ними, решите, какие две являются вашими основными таблицами, и какие поля должны быть разделены между ними. В этом случае таблицы компании и пользователя должны совместно использовать телефон. Скорее всего, вам нужно сделать новый телефонный стол в качестве компоновщика.
Предупреждающий сигнал о недопонимании должен появиться, как только вы решите, что ни один из 3 не работает на вас. Этого должно быть достаточно, чтобы сказать вам, что вы просто неправильно формулируете вопрос об отношениях. С течением времени вам станет лучше, но это необходимый навык, и его действительно нужно освоить как можно скорее для вашей собственной санатии.
Конечно, вы также можете перейти к объектно-ориентированной базе данных, которая позволит использовать ряд других отношений, называемых иерархическими отношениями. Это здорово, если вы думаете стать программистом тоже. Но я бы не рекомендовал это, так как это может повредить вашей голове, когда вы начнете находить способы комбинировать различные типы отношений. Особенно учитывая, что в этом нет особой необходимости, поскольку почти все базы данных в мире состоят только из этих трех типов отношений, если только они не являются чем-то сверхспособным.
Надеюсь, это был разумный ответ. Спасибо, что нашли время, чтобы прочитать его.