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

Если количество номенклатуры хранить в самой номенклатуре, то нужно в этой номенклатуре указывать ее исполнение, место хранения и количество в этом месте.

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

Вот и вопрос, что лучше? А точнее как правильнее по науке?

по науке ничего не надо хранить из того, что можно вычислить

и даже вредно.
можно хранить срез наличия на дату
от него идут вычисления  по документам прихода/расхода.

> А точнее как правильнее по науке?


Правильнее - нормализовать. Т.е. - "создать отдельную таблицу где всего несколько полей"

Номенклатура "КОФЕ в банке"
01,01,2012 Документ прихода, где есть "КОФЕ в банке" 100 штук //Мы купили
02,01,2012 Документ расхода, где есть "КОФЕ в банке" 10 штук //Мы продали
04,01,2012 Документ расхода, где есть "КОФЕ в банке" 30 штук //Мы продали
12,01,2012 Документ расхода, где есть "КОФЕ в банке" 30 штук //Мы продали
12,01,2012 Документ расхода, где есть "КОФЕ в банке" 10 штук //Мы продали
Запрос кол-ва на складе - (+100 -10 -30 -30 -10 = 20)
01,02,2012 Документ прихода, где есть "КОФЕ в банке" 100 штук //Мы купили
02,02,2012 Документ расхода, где есть "КОФЕ в банке" 10 штук //Мы продали
14,02,2012 Документ расхода, где есть "КОФЕ в банке" 30 штук //Мы продали
22,02,2012 Документ расхода, где есть "КОФЕ в банке" 30 штук //Мы продали
Запрос кол-ва на складе - (+100 -10 -30 -30 -10 + 100 -10 -30 -30 = 50)

Со временем, вычисления становятся накладными, делаем срез.
Пусть это было на 01,02,2012
Номенклатура "КОФЕ в банке" на 01,02,2012 (+100 -10 -30 -30 -10 = 20)
тогда
01,02,2012 Документ прихода, где есть "КОФЕ в банке" 100 штук //Мы купили
02,02,2012 Документ расхода, где есть "КОФЕ в банке" 10 штук //Мы продали
14,02,2012 Документ расхода, где есть "КОФЕ в банке" 30 штук //Мы продали
22,02,2012 Документ расхода, где есть "КОФЕ в банке" 30 штук //Мы продали
Запрос кол-ва на складе - ( +20(от последнего среза) +100 -10 -30 -30 = 50)

to AV ©

Т.е. я создаю вторую таблицу, как срез на определенную дату. Например на 00-00 каждого 1-го числа каждого месяца.

В принципе, понятно. А все остальное вычисляю.

Т.е. при создании документа расхода/прихода ничего не вычисляю. А вычисляю только когда запрашиваю остатки.

Но если глянуть в глубь, то запросов остатков всегда больше чем документов расхода/прихода. Даже перед проведением документа, нужно провести анализ остатков. Получается лишняя нагрузка на сервер...

Или сделать еще текущий "срез", для уменьшения вычислений?

>> Или сделать еще текущий "срез", для уменьшения вычислений?
зависит от того как работаете
если не делаете задним числом ничего - вполне можно на вчера иметь, например.

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

аа..

> И складов несколько

поэтому в
01,01,2012 Документ прихода, где есть "КОФЕ в банке" 100 штук //Мы купили
должен быть ид_склада, куда пошло
в расходе, должен быть ид_склада, откуда ушло.

ид_РогаИКопыта от 01,01,2012 продали нам ид_"КОФЕ в банке" 100 шт на ид_склада1

тогда может быть так, что
ид_Аноним от 14,02,2012 купил ид_"КОФЕ в банке" 120 шт с ид_склада1
но там только 100 банок
в итоге там будет -20 банок.
Т.е. реально его просто нагрузили как попало, со всех складов и отправили быстрее, ибо время-деньги.

Тогда делаем документы
ид_склада2 от 14,02,2012 перевел ид_"КОФЕ в банке" ХХ шт на ид_склада1
ид_склада3 от 14,02,2012 перевел ид_"КОФЕ в банке" ХХ шт на ид_склада1
таким образом, выравниваем ситуацию под реальность на складах.

если недостача вдруг где-то
Тогда делаем документ
ид_складаXX от 14,02,2012 испортил ид_"КОФЕ в банке" ХХ шт

т.е.
ВСЕ делается только по "документам".
А что бы не пересчитывать постоянно документы с начала деятельности шараги, и нужен срез на дату.

> запросов остатков всегда больше чем документов расхода/прихода

много, да.
Но необязательно это делать постоянно.
Зачем знать перед продажей сколько у тебя на складе, если человек уже купил?
Пусть склад уйдет в минуса по БД временно..
Потом выравнять документом ревизии/внутреннего перемещения. (например, возможно, документ прихода еще не внесли(ну, тупо забыли).

да,

> Т.е. я создаю вторую таблицу, как срез на определенную дату

да, думаю, так удобнее всего делать. С учетом, что не редактируются документы ранее среза.
Хотя и это не критично. Все срезы могут быть пересчитаны в любой момент. Это для бухов, они ж еще и бумажки делают, те не пересчитаешь просто так :)
Да, хотя.., и бумажки можно, если что вдруг :)

to AV ©

Понял, спасибо за консультацию.

AV ересь вам насоветовал. Студенты так пишут "склад". Или недоученные "прогеры".
Прежде чем садиться что-то писать, необходимо изучить предмет.
Это во-первых
Изучить как устроены известные хорошо зарекомендовавшие себя профессиональные продукты.
Это во-вторых
Делать нормальную постановку и разработку, причем с привлечением профильных спецов - товароведов, бухгалтеров, менеджеров по продажам/поставкам и т.д.
Это в-третьих

1,2,3 - согласен.


> AV ересь вам насоветовал. Студенты так пишут "склад". Или
> недоученные "прогеры".

Из чего это следует?
Что ни слова  нет про принципы БУ, FIFO|LIFO,  т.п.?
Это
1.тема отдельной статьи, предметной области БУ
2.тема для 1,2,3
3.ответом на форуме быть не может.

Что посоветовал ФМ - вершина айсберга работающей системы Симфония/соната компании СБС, в разрезе учета товара. Система рабочая, 2 года магазин работал на ней, примерно на миллион деревом продаж в день было.

>примерно на миллион деревом продаж в день было
работает на срезах?
сколько документов в день?
какая СУБД?

> работает на срезах?
не работает, а предварительно оценивает, для текущих операций
Потом запускается процедура закрытия смены, которая все пересчитывает.
Потом запускается процедура фиксации смен, которая аналогична КТ в 1с

> сколько документов в день?
не помню. Три года не работаю там уже.

> какая СУБД?
MSSQL (200-2005)

закрытие-фиксация на ночь оставляются.
Срез делается после фиксации и запрещает менять документы ранее.
Это - достоверный срез.
Процедуры пересчета имеют параметр (точность/скорость), в зависимости от него смотрят, брать срез/достоверный срез или полный пересчет.


> > сколько документов в день?
> не помню. Три года не работаю там уже.

Человек на кассе берет что-то - документ.
Просто, купил сигареты - документ.
2-3 кассы работали постоянно, перед праздниками до 6-7 касс.
+ операторы приходы колотили, 5 человек с 8 до 22-00, постоянно.

Но вот не помню, даже примерно, хоть убейте, сколько именно в день документов.

>AV ©   (28.04.12 13:31) [13]
>2-3 кассы работали постоянно, перед праздниками до 6-7 касс.
например, пусть один документ в минуту с кассы, работающей круглосуточно; пусть кол-во касс равно десяти: 1440 * 10 = 144000 - кол-во документов в день. При наличии соответствующего индекса(индексов - не ведаю конкретной структуры), необходимость ЕЖЕДНЕВНЫХ срезов неочевидна, мягко говоря. А с учетом того, что при проводке "задним числом" необходимо пересчитывать все срезы от этого числа до пред. дня, так и вообще странная затея. согласны?

>AV ©  

Я извиняюсь, конечно, если что... но с Вами неинтересно дискутировать даже.. После всех этих "принципов БУ", "процедур закрытия-открытия смен" и т.д.
Такое впечатление, что Вам невдомек даже, что существует складской и бухгалтерский учет и это вовсе не одно и то же.
У Вас же в куче все, как на той свалке...

ЗЫ. Это я не к тому, чтоб Вас макнуть или там свой скил выставить, а к тому, чтоб человек, сделавший выводы о том, что Вы ему дали "консультацию", критично еще раз пересмотрел Ваши посты. Или хотя бы учел, что Ваши "консультации" весьма сомнительны.

> MsGuns ©   (28.04.12 15:55) [15]
что существует складской и бухгалтерский учет и это вовсе не одно и то же.

Знаю, что есть. Чем отличается - не знаю. Мне это не требовалось
Насчет >> с Вами неинтересно дискутировать даже..
Не собираюсь. Я сказал, как это работало у нас.
складской и бухгалтерский учет, суть разные вещи были объединены в логические процедуры "свертки". Закрытие и фиксация смены.
Насчет критичности - согласен, все надо критично воспринимать.

Или Вы думаете ,что после моих советов, автор пойдет и напишет с2с, на которую посадят лично Вас и заставят работать? :) А Вы будете плеваться..
Скорее всего, нет.
Автор, наверное ,пишет небольшой магазинчик, а, что представляется вернее, курсач. Если что-то серьезное - такие вопросы не возникают обычно.
(возникают только чисто технические, аля оптимизировать код/выбрать индекс)

>> Кщд   (28.04.12 15:17) [14]

> пусть один документ в минуту с кассы, работающей круглосуточно;
>  пусть кол-во касс равно десяти: 1440 * 10 = 144000 - кол-
> во документов в день. При наличии соответствующего индекса(индексов
> - не ведаю конкретной структуры), необходимость ЕЖЕДНЕВНЫХ
> срезов неочевидна, мягко говоря.

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


> с учетом того, что при проводке "задним числом" необходимо
> пересчитывать все срезы от этого числа до пред. дня, так
> и вообще странная затея. согласны?

Наверное..
Ежедневный срез нужен был утром бухгалтерии, для ускоренного формирования отчетов. Так реально быстрее выходило, проверено опытным путем. Потом они же эти срезы и портили, т.к. кроме них никто задним числом ничего не вносил.

Это в закрытой смене.

А еще есть зафиксированная смена.
Этот срез трогался (обычно, 14 дней взад делался) только по письменному распоряжению глав.буха. По нему же финансовые сворачивались.
В идеале, от последнего такого среза вниз можно было все удалить, и все останется работать(конечно, история утеряна будет).

Это актуально было, когда на кассе место кончалось (там таже идеология, собственный сервер, с центральным зареплицированный. Но! Бесплатный, SQLExpress. До 2 ГБ доходит, фиксируется, отрезается, идем дальше. А на основном все есть. т.о. одна лицензия на MSSQL на всю контору нужна.)