asdfghjkl _QWE_разве дело вкуса?!
Пока у меня за год ~20 тысяч записей. Проекты схожи и очень малы. Ни в одном из них я пока не столкнулся с тем что надо думать над чем то более чем каждый товар отдельная запись.
Ни с точки зрения масштабируемости ни производительности ни одновременной работы пользователей и так далее.Именно его. :-) Пример от AlexTheRaven - нормален как вариант, он уже дает понимание запасов.

_QWE_Очевидный момент привёл 4321 про аналогию с песком, можно взять нечто более реальное.
Для примера: в день приходит X партий, где Y моделей товаров по Z штук.
Соответственно в первой модели будет X*Y*Z записей, во второй X*Y, очевидно отсюда и растут ноги у проблем с производительностью.Что-то мне подсказывает, что есть проблемы с пониманием понятий "запас" и "движение" и их отношений. :-) Не стоит все валить в одну кучу ("таблицу"), обычно это разные "таблицы". Просто удобнее. А проблема - "ой, триггер не обновил остатки!" - от кривизны рук/архитектуры и не более. :-)

По-видимому, должна быть таблица "партии"

Номер партии Наименование товара Количество Единица измерения Есть на складе1 Пиво 1 Бутылка Нет2 Пиво 5 Бутылка Нет3 Пиво 6 Бутылка Нет4 Два пива 3 Упаковка Нет5 Два пива 1 Упаковка Нет6 Два пива 2 Упаковка Нет7 Два пива 1 Упаковка Да
и таблица "движения"

Номер партии откуда Номер партии куда Тип перехода1 3 Объединили2 3 Объединили3 4 Упаковали4 5 Разъединили4 6 Разъединили5 NULL Продали6 7 Усушка
и сразу видно, сколько упаковали, сколько продали, а сколько "усушили" :). А "остатки" - это как раз

Наименование товара Количество Единица измеренияДва пива 1 Упаковка
- вьюха, не более...

4321<...>
>>поправлю
<...>
Ну, я имел в виду именно количество продукта, оставшегося на складе, в зависимости от наименования и вне зависимости от партии. Конечно, по ключику можно всё узнать, но зачем делать в два действия то, что можно сделать в одно?

4321<...>1. Допустим партия у вас содержит кудыть больше данных. (ну просто характеристик у ей до фига - в т.ч. сроки порчи, и т.п.).<...>
На 100% согласен.

4321
2. Допустим, что мы пользуем версионник.

"Версионник" в данном случае означает "темпоральное расширение СУБД"? Если да - то IMHO экзотика. Если нет - то тоже экзотика: то, что СУБД называется "версионник", совсем не означает, что мы сможем стандартным способом (через SQL) получить доступ к предыдущей версии записи. В лучшем случае - с использованием функций, специфических для конкретной СУБД.

4321
3. Спрашиваеца: на кера строить версии длинных записей Э"партии", кады "апдейтятся" только поля количеств ("остатков").

Чтобы понять, сколько было, сколько стало и куда ушло. Если не строить - перестанут быть видны переходы из одной партии в другую. Лично для меня такой принцип кажется проще, чем городить огород с одним полем, значение которого изменяется во времени. Тем более, таблица при этом остаётся хоть и с трудом, но читаемой без помощи нашей системыю. А это одно из требований ко многим системам учёта.

4321
- Т.е. имеет смысл поделить на собственно данные (вводим один раз и не трогаем без нужды), и собственно (денормализованный) агрегат - остатки. - уж положено им все время апдейтиться - так и мозгуем только как их сделать быстро обновляемыми.
Реализация как реализация. Только на мой вкус - сложнее. Наверное, мы, как ни странно, называем остатками разные вещи.

4321вы можете иметь что угодно. В том числе и ввиду.
Неадекватно резко.

4321
Партии сплошь и рядом - это "реально" разный товар. Позавчерашний кефир не равен сегодняшнему. И сотатки по нему нужны отдельно.
Позавчерашний кефир - это как раз товар класса "кефир", подкласса "дата производства 2006-12-27".
Если мне сегодня привезли позавчерашний кефир - он ничем не отличается от свежего, который мне привезли позавчера. И остаток по нему на сегодняшнее завершение дня будет один.

4321
пример не в том,чтобы получать доступ к версиям, а в том, чтобы не шуршать дисками без надобности. Или вы будете утверждать, что дисковые операции - не узкое место СУБеДей? (кстати, еще вопрос, будут ли при этом лишние перестройки индексов и прочей "неявной" обвязки)

Почему в гроссбухе не пишут карандашом и не стирают ластиком? И почему в нём вообще пишут - можно же так запоминать?
Принцип учёта - согласованное отображение всех операций. Другой учёт никому не нужен.
Способ же реализации учёта может быть разным.

4321
Да и для блокировочника - лучше блокировать только те данные, которые реально меняются, а не всю запись.
Блокировку на уровне таблицы, страницы, записи вживую видел. На уровне поля - не видел. IMHO разрушит изоляцию транзакций. Пример: один правит название товара в партии, а другой - количество в той же партии. И что получится?

4321
Тут Вы возражаете не мне. Я собираюсь иметь отстатки, но иметь именно в отдельной сущности (в ней же иметь не только текущие остатки, но и остатки на опорные даты - с тем, чтобы запрос по оборотам за период не приводил к пересчету всех движений с момента первой записи.

Я вообще не возражаю против Вашего решения - я высказываю свою точку зрения. И никому её не навязываю. Нужно - имейте.

AlexTheRavenмало ли что и кому нравится
Почти всегда есть несколько возможных решений и нет объективного способа их сравнения. Особенно в архитектуре. Так что выбор архитектурного решения всегда субъективен. Тот, кто считает, что его решение объективно, обманывает себя.

AlexTheRaven
По части же "одного из требований" - не понял. Имхо, ничего кроме ХМЛ-подобных систем вас не спасет. В противном случае читаемость - субъективное понятие. Иной идиот и децкие книшки не прочтет.
Вы читали XML? Размером... ну хотя бы 10 Кб? В котором конструкции между собой хитро связаны? Хорошая человеко-читаемость "сырого" XML - миф. Хотя согласен, иной человек и бинарник рисунка прочитает, а другому и таблицы Брадиса непонятны.
Между тем, требование очень простое. Структура таблиц должна быть понятна специалисту, знающему предметную область. Должна быть возможность скорретировать их сторонними средствами, без знания средств и особенностей реализации.

AlexTheRavenвкус - не критерий. Видимо мы имеем в виду разные задачи.
Видимо мы имеем в виду разные решения одной задачи.