Confused on SQL Relationships

Question

Я смущен в отношениях SQL, особенно с One to One и One to Many. Я прочитал много статей, как this и this

Для примера ниже приведены некоторые высказывания из этих статей и некоторые другие статьи

1. Отношение между клиентами и адресными таблицами один к одному, то есть потому, один адрес принадлежит одному клиенту.

2. Взаимосвязь между таблицами клиентов и заказов является одной для многих, то есть потому, что один клиент может сделать много заказов.

3. клиенты и КонтактныеДанные таблицы один к одному, потому что один КонтактныеДанному принадлежат одному клиенту

Да, верно, но взять мой аргумент в настоящее время.

• В пункте 2 говорится, что отношения являются одними для многих, но один заказ относится к точной право одного клиента? Таким образом, вы можете рассматривать его как один к одному.
• В пункте 3 contactData и отношения с клиентами называются один к одному, но один клиент может иметь много contactData правильно? Так что это одно для многих

Со всем этим я серьезно запутался. Может ли кто-нибудь дать мне четкое определение о том, как найти отношения, пожалуйста?

Answer 1

Взаимосвязь между таблицами клиентов и заказов является одной для многих, то есть потому, что один клиент может сделать много заказов.

Это должно лучше прочитать

• клиент может разместить много заказов
• порядок принадлежит один клиент

Так это один ко многим отношения между таблицами.

клиентов и КонтактныеДанные таблицы один к одному, потому что один КонтактныеДанные принадлежат одному клиенту

Это должно лучше прочитать

• КонтактныеДанные принадлежит один клиент
• клиент может иметь только один контактData

Таким образом, это взаимосвязь между таблицами.

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

EDIT: Я должен добавить, что вы можете сказать, что между таблицами a и b существует соотношение «один-много», в котором не указывается, что именно, поэтому вы можете быть более точным, говоря «есть один для многих отношений из таблицы a в b "или" существует множество отношений от таблицы b до ". Конечно, у вас нет такой проблемы. (Добавляя к этому, существуют еще более точные определения, такие как «один к одному» или «ноль» и т. Д., Где вы указываете, разрешены ли нулевые записи, например лицо без контактных данных.)

Answer 2

Dongle. Вы делаете ошибку, рассматривая объект симметрично. Отношения считаются однонаправленными, поэтому вы сбились с толку.

Возьмем, к примеру, этот Клиент < -> Заказ отношение. Как вы заметили, клиент -> заказ - это нечто совершенно иное, чем заказ -> заказчик. Они на самом деле независимы, какими бы странными они ни были. Это потому, что в реальном коде вы никогда не имеете дело с двумя объектами одновременно, а не «действуете» с точки зрения одного из двух. Например. вы выбрали объект заказа из db, и только тогда вы являетесь клиентом, который сделал этот заказ. Или у вас есть объект клиента, и вы хотите проверить, каковы его заказы.

Как вы видите, это очень однонаправленный (мы называем отношения одно- или двунаправленными). У вас есть объект X, и вы хотите «улучшить» свои знания об этом, присоединив его к другой таблице, к объекту Y. Так что это X-> Y. Или Y-> X. Но на самом деле это не X < -> Y. Вот почему вы всегда должны смотреть на отношения, как если бы они были независимыми.

Кроме того, вы правы, и это обычно бывает так, что один отношение один к одному и другой один ко многим.

Answer 3

Пункт 2 явно one to many, потому что один customer может иметь несколько orders но каждый order принадлежит ровно один customer.

Вы должны прочитать отношения в обоих направлениях.

Представьте себе это отношение был one to one. Вам нужно будет создать новую учетную запись клиента каждый раз, когда вы хотите разместить новый заказ.

Точка 3, вероятно, вопрос дизайна. Если вы хотите разрешить несколько contactData, нет никаких оснований хранить его one to one.

Answer 4

Ваша точка 2 - ответил Рав.

«пункт 3»: я нашел в одном из ваших первых ссылок один к примеру с таблицей «Адреса». В этом примере клиент может иметь только один адрес. Поэтому, если у ваших клиентов может быть больше одного, вам понадобится один для многих (как в примере Orders).