Отношения один-к-одному или один-ко-многим?

Question

Может быть, мне нужно больше кофе сегодня утром, но здесь идет ...

У меня очень простая система инвентаря. Прямо сейчас у меня есть две таблицы: Предметы и Инвентарь.

Предметы
Id
Название
Год выпуска

Inventory
Id
ItemId (внешний ключ для Items)
Количество
Количество на руках

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

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

Я вижу несколько вариантов:

1.) Удалите автоматически увеличивающееся поле идентификатора в Inventory и живите с чувством грязи.
2.) Сохраняйте таблицы как есть.
3.) Объедините предметы и инвентарь в одну таблицу: ItemsInventory.
4.) Что-то еще?

Answer 1

Если ваши отношения действительно один к одному, уберите Id из таблицы инвентаря и используйте ItemId в качестве PK и FK.Также назовите обе клавиши ItemId - подсказки.

Answer 2

Если вы уверены, что сопоставление всегда будет 1: 1, объедините две таблицы в одну.

Однако уверены ли вы, что отношение всегда будет 1: 1?

Answer 3

Поскольку для многих ORM требуется один PK с автоматическим приращением, я бы:

4) добавил уникальный индекс к Inventory.ItemId, и он должен отображаться как отношение один к одному.

Answer 4

Если вы действительно хотите сделать это простой системой инвентаризации, объедините таблицы.

Причины не объединять таблицы / не все так просто.

Сколько предметов НЕ будет иметь инвентарную запись? Ваш пример показывает только несколько полей инвентаря и, возможно, это все, что когда-либо будет. Но если поля, которые вы отслеживаете в инвентаре, растут, и есть большая часть предметов, которых нет в инвентаре, у вас будет много пустых полей.

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

Answer 5

Я бы объединил две таблицы, моя главная причина в том, что у вас будут дубликаты данных а также ненужные данные, если вы придерживаетесь двух таблиц. Запросы также будут быстрее! Глядя на две таблицы, я наверняка слился бы в одну.

Пункты Я бы заглавие Год выпуска

Inventory Я бы ItemId (внешний ключ для Items) Количество Количество на руке

У вас будет на два столбца меньше данных, если вы объедините одну таблицу («ID» ItemID »может быть удален). Написание логики для извлечения и отправки данных в базу данных также будет проще для вас.

Я бы имел эту таблицу:

**ItemsInventory**
Id
Title
YearReleased 
Quantity
QuantityOnHand 

Однако вы должны быть уверены, что это один, иначе вам может потребоваться много работы, если бизнес нуждается в изменении.

Simon

Answer 6

Если структура таблицы, которую вы упомянули, останется такой же, как сейчас, то я думаю, что вы должны объединить Предметы и Инвентарь в одну таблицу: ItemsInventory.

Для таких маленьких таблиц не имеет смысла разбивать их по вертикали. Таким образом, вы удалили бы дополнительное соединение. Выбор на одном столе всегда быстрее, чем объединяет.

Answer 7

Будет ли недостаточно, чтобы ItemId имел ограничение на уникальность? Это, кажется, удовлетворяет вашим требованиям.