Добрый день!

Проектирую базу данных (под mysql-server) . Помогите с оптимальной архитектурой (есть пару идей) :

Торговая фирма получает от поставщиков товар (имеет различные категории и вложенные подкатегории) по "накладным Прихода". Товар распределяется по нескольким магазинам. Для каждой категории/товара идёт своя наценка.

Цена для товара может меняться: во время Прихода(изменение у поставщика), скидка, уценка. Соответственно на складе один и тот же товар в разных магазинах может иметь разную цену (не большой процент) .

Со склада магазина товар списывается: Уход, Продажа либо Списание (Брак/Воровство/представительтские цели/хз что - можно примечанием оформлять =)) .

Количество магазинов(складов) 4-ре, но будет увеличиваться.



Задача:
Переучёт раз в 1-3 месяца.

1.До переучёта нужно видеть всю историю по товару: кто и сколько принял на склад, кто и сколько продал, когда, по каким ценам?
2.Иметь актуальный склад (да считаем, что Приход/Уход/Продажу люди заполняют) по каждому магазину.
3.Получить "сверочные" данные для реального переучета.
4.После переучёта (можно конечно же непрерывно сохранять) данные можно архивировать, менять структуры, хранить по другому.
Аналитика по продажам/складу(что лучше продаётся, какая прибыль с данного товара за год, определение сезонности и т.д.) не в риалтайме. Другими словами данные должны занимать меньше места и давать меньше нагрузку.



Расчёт:

Товарных позиций порядка 5000 на любом магазине-складе.
В общей "таблице" Приход пополнение на 3000 записей/месяц
В общей "таблице" Продажа пополнение на 9000 записей/месяц



мысли и варианты:

Итак склад --- это
автор* Приход, Уход, и Остаток (либо Приход-Уход)
* Либо Склад = Текущий Остаток


Вариант №1.

Товар храниться в таблице Storehouse (различается по цене, складу - idx_prid_price_whid_UNIQUE). Принадлежность разным магазинам ( warehouse_id).


Плюсы:
мало таблиц
Минусы

Actions достигает ~100000 за 1 период переучёта

Storehouse - 20000 ( кол товара * кол магазинов)


Вариант №2

Берём предыдущий вариант и разбиваем таблицу Actions на 3-и таблицы: Приход, Уход (передача на другой склад, списание и т.д.), Продажа.

Плюсы:

не так много таблиц
Минусы

Продажа достигает ~10 000 строк за 1 период переучёта

Приход ~4000 строк

Storehouse - 20000 строк ( кол товара * кол магазинов)



Вариант №3

Берём Вариант №1 и делаем так, что бы в Storehouse были записи уникальные относительно Товара и дополнительно создаём таблицу ProductPriceWarehouse в которой храним: количество данного товара, цену на определенном складе.




Плюсы:

не так много таблиц

Storehouse - 5000 строк

ProductPriceWarehouse Уникальный ключ на два поля (price, product_id_)

Минусы

Продажа достигает ~10 000 строк за 1 период переучёта

Приход ~4000 строк

ProductPriceWarehouse ~ 20000 строк


Вариант №4
Как и в варианте №2 - таблицу Actions разбить на 3-и таблицы.

Вариант №5
пока нет мыслей.

mwb-файлы для mysql-workbench:

Вариант 1
Вариент 3

Negruzzi CristianС точки зрения нормализованности - никаких проблем нет.
Почему не использовать отдельные таблицы Приход, Расход ... ?
Вариант 4 - (болею и за компом не сижу- то все что успел нарисовать а читаю с планшета)