Нужно хранить логистические данные для последующего статистического анализа

Вопрос в том - какой вариант проектирования лучше ? (идеологически, и по быстродействию)
А то я про нормальные формы читал, но так и не вкурил к какой форме относятся эти 2 варианта .

Имеются связи с: т. Товары, т. Магазины, табл. Поставщики

Вариант 1 : с 1й таблицей "Операции" :
Поля: Н_недели, Товары_код, Магазины_код (ключевые), количество_закупки, цена_закуп, количество_продажи, цена_розн, количество_перемещения, количество_наличие, ну и поставщики_код итд.

Вариант 2 - разбить на 4 таблицы: Закупки, Продажи, Перемещения, Наличие
В каждой те же 3 ключевых поля Н_недели, Товары_код, Магазины_код , + специфика

В 1 варианта естественно, некоторые поля будут null

Объем БД - 3-4млн строк для таблицы Операции (1й вариант проектирования) или для таблицы Наличие, другие таблицы в несколько (или несколько десятков) раз меньше

SERG1257
Давайте ваши факты

0 Такого то числа, такой то товар, в таком то магазине , был в наличии в таком количестве, по такой то цене
1 Такого то числа, такой то товар, в таком то магазине , продан такого то количества (цена подразумевается из наличия)
2 Такого то числа, такой то товар, привезен в такой-то магазин , от такого то поставщика, количество, цена.
3 Такого то числа, такой то товар, из такого-то магазина/склада , был перемещен в количестве штук (т.е. сумма на любое число,товар по всем магазинам = 0)


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

Боюсь только что
1. Шерстить долго будет, если при каждом запросе
2. По причине раздолбайности тех кто вносил данные, наличие_нов не всегда = наличие_стар +-приход,перемещения,продажи. Даже боюсь проверять этот факт :-)


В зависимости от ваших данных и операций с ними (загрузка, запросы) определяется конечные таблицы (что-то денормализуется, что-то объединяется, что-то секционируется)

Операции даже не знаю какие точно будут, будет анализ различный статистический, abc-анализ, много сводных таблиц, итд.


p.s. спасибо огромное за ссылки!

Ortogon
1. При правильно построенном индексе ничего тормозить не должно, хотя это конечно зависит, на чем у вас база сидит. Но без этого у вас рано или поздно остатки с оборотами начнут расходиться, мало ли где кто чего ручками в базе подправит :)
2. Если это равенство не выполняется, тогда вообще непонятно, зачем это все автоматизировать. :)
Лучше уж сделать доп тип операции "инвентаризация", на который списывать все расхождения, если уж так все страшно.

Да у меня вобщем-то не база не для автоматизации, а как правильно заметил SERG1257, хранилище данных.
А именно, я перегоняю 4Гб excel-файлов в MS Access для статистического анализа (каждый excel файл по 30мб, импортируется, нормализуется скриптом, и эти данные занимают в результате в базе около 3мб). А т.к. импорт такого количества данных в моем случае операция не быстрая, хотелось бы перед импортом всем данных определиться со структурой таблиц. Вот и прошу совета с этим...

SERG1257
baleks А именно, я перегоняю 4Гб excel-файлов в MS Access для статистического анализа (каждый excel файл по 30мб, импортируется, нормализуется скриптом, и эти данные занимают в результате в базе около 3мб).это каждый день или разово?
Это разово. Данные реального предприятия за 2 года, для анализа. Пишу диплом :).

p.s. данные у меня не по дням, а по неделям. импортируемые из экселя данные - по 1му 30-60мб файлу на каждую неделю)