2014-12-15 7 views
0

У меня есть модель под названием Addresss, которая, как название звучит, представляет собой список адресов.Является ли мое отношение «один-ко-многим» или «много-ко-многим»?

Эти адреса могут принадлежать Client, и клиент может иметь многие из этих адресов.

Чтобы связать эти адреса клиента, я просто таблица называется ClientAddress с 3-мя столбцами: id, client_id и address_id.

Является ли это примером отношения one to many или many-to-many? В настоящее время у меня есть настройка как отношения ManyToMany в Phalcon, но я не уверен, действительно ли это должно быть One to Many.

+0

Могут ли два или более клиентов иметь одинаковый адрес? Если да, то это много для многих, иначе один для многих. –

+0

С точки зрения бизнес-правил, нет, но технически это может произойти с точки зрения базы данных. Мое понимание заключалось в том, что если у меня есть промежуточная таблица, которая связывает «адрес» с «клиентом», то это означает, что это «m: n' .. это неверно? – Lock

+1

Если это не должно происходить с точки зрения бизнес-правил, вам необходимо выполнить это требование через вашу модель данных. Он должен быть смоделирован как отношение «один ко многим». –

ответ

2

Это отношение «один ко многим». Один клиент (может) имеет несколько адресов. Один адрес принадлежит только одному клиенту.

Что касается таблицы clientAddress, я бы избавился от нее, так как вы можете хранить идентификатор клиента в таблице адресов.

Если, как ваши метки предполагают, что вы используете Phalcon и решить, действительно идут с ОРМ Phalcon Вам необходимо взглянуть на документацию: Working with Models

0

Ее все зависит how you are thinking about your Entities

Начнём с Client
Мы хотели бы хранить информацию о Client. Теперь, если наш Client имеет только один конкретный Location, тогда у нас есть два варианта. Мы можем непосредственно хранить Address информации в одной таблице в как- таблицы

клиентов id, f_name, l_name, address, current_city, home_city, etc.... В этом случае нет ничего о Relation

Если вы заинтересованы, то вы можете разделить эту таблицу и хранить Location информации о другую таблицу, которую вы можете назвать addresses. Затем Relation между Client и Address будет иметь отношение one-to-one.

Теперь, если наш Client имеет другой офис на разных Location, тогда необходимо хранить Location информацию о другой таблице. Тогда Relation будет one-to-many, так как наш Client имеет другое `Местоположение '.

Теперь, если у нас есть много Client на одном Location (одном здания может быть), и наша Client имеет много офиса во многих Location то это будет как many-to-many отношения. Как ClienthasManyAddress и AddresshasManyClient мы НОВИНКА pivot или intermediate таблицу для хранения нашей Relation информации.

0

Это зависит от того, насколько сложна ваша модель.

Предположим, что ваши «клиенты» являются филиалами национальной компании. Eech «клиент» может иметь несколько адресов - адрес доставки и адрес выставления счетов, например.И в равной степени, поскольку функция кредиторской задолженности может быть централизована либо в региональном, либо в национальном филиале (который может сам иметь или не иметь «адрес доставки»), платежный адрес, скорее всего, будет использоваться среди многих «клиентов».

Итак, в этом случае многие-ко-многим.