Архитектура инвентаризации в базе данных

Это вопрос не к конкретному языку, а к правильной методологии архитектурного обращения с инвентарем.

Рассмотрим следующую структуру для хранения программного обеспечения:

platforms (platformID*, platformName)
titles (titleID*, titleName)

А ниже столярная таблица для уникальных изделий

products (platformID*, titleID*, releaseDate, notes)

Ниже приведена таблица, в которой я хотел бы отслеживать свой инвентарь.

inventory (platformID*, titleID*, quantityAvailable)

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

software(softwareID*, softwareTitle)
inventory(inventoryID*, softwareID*)

Я хотел бы знать, какой подход предпочтительнее? Должен ли я создать inventoryID и, следовательно, строку для каждой уникальной копии программного обеспечения:

inventory(inventoryID*, platformID*(fk), titleID*(fk))

Или используйте вместо этого таблицу, в которой хранится количество, например:

inventory(platformID*(fk), titleID*(fk), quantityAvailable)

mysql architecture inventory database-design
person Mohamad    schedule 19.02.2010    source источник
comment
Я упустил из своего вопроса важную деталь; то есть я планирую отслеживать запасы, предоставленные взаймы. Не знаю, как это повлияет на мои планы.   -  person Mohamad    schedule 19.02.2010

Ответы (3)


arrow_upward
1
arrow_downward

Я бы также начал с количества в наличии вместо строк для всех товаров. Но я бы все же выбрал inventoryId, так как могут возникнуть случаи, когда вам придется анализировать записи с одной и той же комбинацией платформы/названия — с inventoryId вы сможете улучшить свои возможности в будущем.

Я бы также рекомендовал добавить еще один столбец: versionNo --- номер версии программного продукта. Иногда у вас могут быть разные версии одного и того же продукта. Когда у вас есть это, не рекомендуется размещать информацию в заголовке (например, вы хотите искать все продукты «Microsoft Office» независимо от версии ...).

person Juergen    schedule 19.02.2010
comment
Юрган, спасибо за ответ. Я добавил комментарий выше, что упустил важный факт: я хочу отслеживать, где находится предмет инвентаря (если это, например, игра или фильм, я хотел бы отслеживать, с каким покупателем он находится в настоящее время), и я Я не уверен, как это должно повлиять на мое планирование. - person Mohamad; 19.02.2010
comment
Привет, Мел, мне кажется, что такая информация принадлежит объекту инвентаризации. Вот одна из причин, почему inventoryId был бы полезен (конечно, в качестве первичного ключа) — поскольку вы можете получить несколько записей инвентаря с разными свойствами. Конечно, вы по-прежнему можете выбрать одну строку для каждого предмета, поскольку, когда ваш инвентарь часто делится, с отдельными записями легче обращаться как со сводными записями, которые вам придется разбивать каждый раз, когда один предмет предоставляется покупателю .... - person Juergen; 19.02.2010
comment
Еще одна мысль: вы можете захотеть иметь собственную таблицу для мест (или клиентов), в которые может попасть ваш инвентарь (не только текстовое поле). - person Juergen; 19.02.2010
comment
Спасибо Юрген. Это становится настолько сложным, что я последую вашему предложению и начну с количества доступных. Я буду делать дополнения по мере продвижения и делать некоторые тесты. Я ценю совет. - person Mohamad; 19.02.2010

arrow_upward
2
arrow_downward

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

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

person Pace    schedule 19.02.2010
comment
Спасибо, Пейс. Вы могли заметить, что я непреднамеренно упустил важную деталь, когда задавал свой вопрос: я планирую отслеживать запасы на основе клиентов, которые их одолжили. Например, я хотел бы отслеживать, где находится инвентарь/с каким клиентом. - person Mohamad; 19.02.2010

arrow_upward
1
arrow_downward

Должен ли я создать inventoryID и, следовательно, строку для каждой уникальной копии программного обеспечения?

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

Или вместо этого использовать таблицу, в которой хранится количество?

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

person Daniel Vassallo    schedule 19.02.2010
comment
Спасибо, Даниил, я добавил дополнительный комментарий к нижней части вопроса о том, что я полностью изменю суть проблемы: отслеживание запасов на основе клиента, у которого он есть. - person Mohamad; 19.02.2010