Макет базы данных POS

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

Хотя это лучше, чем наличие столбца для количества каждого магазина в таблице «Товары», кажется, что это тоже несколько уродливое решение, так как при добавлении нового магазина вам нужно выбрать новую таблицу, а при добавлении нового товара , вы должны вставлять не только в таблицу элементов, но и в каждую отдельную таблицу магазина.

Есть ли лучший способ сделать это, чем то, как я это вижу? Такое ощущение, что есть.


person Matt    schedule 13.01.2010    source источник


Ответы (4)


Почему бы не иметь таблицу запасов с SKU, StoreId и запасами?

e.g.

Sku    | StoreId   | StockLevel
1234   | 001       | 15
1235   | 001       | 16
1234   | 002       | 8
1235   | 002       | 0

Итак, в магазине 002 нет артикула 1235, но в магазине 001 есть много. Этот макет таблицы также позволяет вам получить общее представление об уровне ваших запасов в одной таблице, используя что-то вроде

select sku, sum(StockLevel) from stock group by sku
person ZombieSheep    schedule 13.01.2010

Следуя правилам нормализации данных, вы хотели бы создать такую ​​таблицу:

store_id | sku    | quantity | other_attributes ... 
---------+--------+----------+---------------------
    1000 | 129832 |      234 |                  ...
    1000 | 129833 |      334 |                  ...
    1000 | 129834 |       23 |                  ...
    1001 | 129832 |        0 |                  ...
    1001 | 129833 |       12 |                  ...
    1001 | 129834 |       10 |                  ...
    ...

По сути, это таблица store_inventory. Таким образом, вы можете отфильтровать до определенного магазина, сказав

WHERE store_id = 1000 

и т.д...

person gahooa    schedule 13.01.2010

Насколько я вижу, вам действительно нужны три таблицы:

Продукт

ProductID
Price
Description
...

МагазинПродукт

ProductID
StoreID
Quantity
...

Магазин

StoreID
Address
...

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

person Mark Pim    schedule 13.01.2010

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

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

Например

Предметы

ItemKey
Название
Цена
Артикул

магазины

StoreKey
Имя
Адрес

Инвентарь

StoreKey
ItemKey
Количество

Использование вместе StoreKey и ItemKey в таблице Inventory сделает ваши записи уникальными.

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

person ManiacZX    schedule 13.01.2010