База данных дизайна инвентаря с цветами и размерами
Я планирую сделать дизайн базы данных инвентаризации, чтобы отслеживать, что у нас есть в нашем магазине. Я думаю о сохранении массива в базе данных всех размеров и цветов, таких как:
array('S-groen' => 6,'M-groen' => 0,'L-groen' => 2,'S-zwart' => 9,'M-zwart' => 0,'L-zwart' => 3);
Где S — размер, а groen — цвет.
Но стоит ли так делать, или есть лучший способ?
Итак, моя база данных будет: ID — product_id — aantal. В анантале будет массив.
Решение
Не храните несколько значений в одном столбце в реляционной базе данных — это обычно считается плохой практикой.
Было бы лучше иметь две таблицы, одну с названием продукта и идентификатором продукта, а другую для вариантов (имеющие столбцы Вариант_ид, идентификатор_продукта, размер, цвет, количество). Столбец product_id в таблице вариантов будет внешним ключом таблицы продуктов.
Другие решения
Как уже говорили другие, не делайте массив. Массивы трудно читать, трудно обрабатывать и сложно запрашивать.
Вместо этого сделайте таблицу цветов и таблицу размеров.
Таблица размеров, вероятно, имеет только идентификатор размера и описание размера. Идентификатор может быть целым числом с автоинкрементом, например, 1 = маленький, 2 = средний, 3 = большой, независимо от ваших размеров. Поскольку размеры обычно идентифицируются короткими сокращениями, вы можете использовать сокращение в качестве первичного ключа: «S» = маленький, «M» = средний и т. Д. Первичные ключи должны быть короткими, но типичные сокращения размера редко бывают длиннее 4 символов — — XXXL — такой же размер или меньше целого числа в большинстве механизмов баз данных (целые числа обычно составляют 4 или 8 байтов).
Аналогично, таблица цветов связывает идентификатор цвета с именем цвета. Опять же, идентификатор может быть целым числом: 1 = красный, 2 = зеленый, 3 = оранжевый и т. Д. Или вы можете сделать короткие сокращения.
Теперь давайте на мгновение проигнорируем эту проблему и сделаем шаг назад.
У вас должна быть таблица продуктов, содержащая различную информацию о продукте, такую как описание, производитель, цена, системы инвентаризации, над которыми я работал, всегда есть куча таких вещей, как категория продукта, вес отгрузки, коды для учета, что угодно. В некоторых системах инвентаризации вы просто сохраняете количество каждой позиции в записи о товаре. То есть, если у вас есть 20 виджетов на складе, то в записи виджета у вас есть поле для «количества», и вы сохраняете число 20. В других системах инвентаризации есть запись для каждого элемента в запасе, то есть это дополнительная таблица «инвентарь» или «инвентарь» с одной записью для каждого предмета, и если у вас есть 20 на складе, то у вас есть 20 записей.
Если у вас есть записи о товаре, вы МОЖЕТЕ добавить поля размера и цвета — внешние ключи к таблицам размера и цвета — в запись о товаре. Это было бы хорошим ответом, если бы не было никакой дополнительной информации, связанной с сочетанием размера и цвета.
Но я предполагаю, что у вас есть штрих-коды на ваших продуктах, и, по крайней мере, так, как это делается здесь, в США, у вас есть разные штрих-коды для каждого размера и цветовой комбинации. Поэтому, если вы поместите размер и цвет в запись товара, вам придется повторять штрих-код в каждой записи товара. Дублирующиеся данные = плохо. Возможно, у вас есть другие данные, связанные с размером и цветом.
Лучше, как говорит stwalkerster, создать запись о «вариациях продукта». Тогда эта запись будет иметь указатель на запись продукта, указатель на запись размера и указатель на запись цвета. Он также будет иметь значение штрих-кода и любые другие общие данные. Тогда запись позиции запаса будет указывать на запись изменений продукта, а не запись продукта. То есть у вас будет 3 уровня: продукт, у каждого продукта есть много вариантов, у каждого варианта есть много товаров на складе.
Если вам не нужны отдельные записи товара, вы можете просто сохранить количество в записи варианта продукта.
Возможно, вы поместите информацию о размере и цвете в запись о продукте и не будете нуждаться в двух уровнях. Но это почти наверняка создаст много дубликатов данных. Я предполагаю, что если у вас есть, скажем, рубашка определенного стиля, которая доступна в различных размерах и цветах, то у этой рубашки должно быть как минимум описание: «Оксфордская мужская классическая рубашка с пуговицами» или что-то еще. Вы не хотите повторять это описание для каждого размера и цвета. Мало того, что на жестком диске много места впустую, но теперь вам нужно беспокоиться о том, что пользователь печатает его немного по-другому, и тогда вы не можете быть уверены, что «Оксфордская мужская классическая рубашка с цветом пуговицы» одинакова как «Классическая рубашка, Оксфорд, мужской» или нет и т. д. У вас, вероятно, также есть учетные коды и т. д., связанные с каждым продуктом, который будет повторяться.
Вы задаетесь вопросом, не будет ли наличие отдельной записи для каждого такого варианта занимать много места на диске и замедлять работу системы.
Но подумайте об этом: на самом деле это займет немного меньше места для вашей таблицы товара. Вместо указателя на запись о товаре, а также указателя в массиве размера / цвета, у вас будет одна точка для записи о вариациях продукта. На одно поле меньше.
Конечно, у вас будет эта дополнительная таблица, таблица вариантов продукта. Но в нем будет примерно столько же данных, сколько в вашем массиве размера / цвета. Я не уверен, думали ли вы, что массив size / color находится в базе данных или жестко задан в программе, но в любом случае эти данные должны существовать ГДЕ-ТО.
Наличие таблицы вариантов продукта должно устранить некоторые избыточные данные. Как я упоминал ранее, штрих-код для варианта будет сохранен один раз. С массивом размера / цвета вам, вероятно, придется хранить штрих-код отдельно и избыточно для каждого элемента с таким размером и цветом. Я не знаю ваших требований, но, возможно, есть другие данные, связанные с сочетанием размера и цвета, которые также необходимо будет повторить.
Единственное наказание, которое я вижу здесь, — это то, что у вас будет много запросов, которые потребуют дополнительного присоединения. Вместо того, чтобы выбирать что-либо из продукта присоединения stock_item, вы должны выбрать что-либо из продукта присоединения stock_item. Но это не должно иметь большого значения, если таблицы должным образом проиндексированы, и за счет исключения избыточной даты каждая запись короче, поэтому они занимают меньше блоков на диске, что должно уменьшить штраф. (В некоторых случаях это может быть на самом деле быстрее.)
detector