1) Остатки бывают простые. На дату-время.
Легко считается в реале.

2) Бывают в учетных ценах
Причем цены могут расчитываться по любому методу списания, причем как по конкретному складу так и по фирме и в принципе и по холдингу.
В реале легко считается по методу средневзвешенных (скользящих) цен и при партионном методе.

3) Бывают по товару, задолженности, денежным средствам, любому другому виду регистров
Перпендикулярно.

4) Бывают в резерве, в брони
Так же.

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

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

--
Шумов В.
http://www.acdplus.ru/

VladSh, обоснуйте ваше мнение.
Пару слов, пожалуйста, КАК ИМЕННО легко считается в реале и ЧТО ИМЕННО легко считается в реале? При каких ограничениях? при каких условиях? Опишите хотя бы схематично...
Оставьте надежду насчет вашей компетентности, пожалуйста.

Прошу прощения у народа, ниже специально для mazzy (он меня в натуре просто достал):

имеем таблицу товара t1 (около 10 млн. строк) с полями:
id - уникальный идентификатор товара
part - зав. номер
kod - оригинальный №
name - наименование и еще пару десятков атрибутов в таблице
part kod
a01 a01
z001 a01
k777 a01
q444 a01
таблица t2 - движение товара (свыше 10 млн. строк) с полями:
id - уникальный идентификатор товара
dat - дата
vid - ссылка на вид накладной (приход, расход, заказ и прочее)
vidnum - знак (+1 - приход, -1 - расход, 0 - заказ)
kol - количество
...

Возможных вариантов запросов к ним множество, вот один из них (расширенный поиск):
по заводскому № (z001) или только по начальным символам номера показать с учетом замен товар, а также:
- остаток на текущий момент
- заказов поставщикам
- заказов от клиентов
- в том числе зарезервировано.

требование - время выполнения запроса не д.б. более 0,5 сек.

(в реале запрос идет не к двум таблицам, а как минимум к пяти - для проверки доступа пользователя к группе товара, складу, фирме и группе фирм)

требуемое быстродействие на Yaffil/FireBird достигается за счет использования хранимой процедуры.

Очень схематично:
1) for select kod from t1 where part like 'z001%' into ...
получили оригинальный №, которому соответствует заводской
2) for select id from t1 where kod = :kod into ...
получили набор товара различных производителей
3) select sum(vidnum*kol) from t2 where id = :id and -- другие ограничения
into...
получили текущий остаток
почти аналогично считаются заказанные количества и резерв.

опять для mazzy :
при использовании MS SQL подобную фенечку можно было бы написать в одном запросе, он обработал бы достаточно быстро (оптимизатор работает очень эффективно).
На Yaffil/FireBird запрос в лоб зависает на десятки минут.
При использовании хранимых процедур и правильного построения индексов требуемое время (0,5 сек) тем не менее достигается.
К сожалению, быстродействие повысить можно только опытным путем
(большинству известно, что оптимизатор в Yaffil/FireBird далек от совершенства).

VladSh, я удалил ваши рекламные и сообщения без обоснований.

Мне это по фигу.
Извините пожалуйста, но других слов найти не смог.

--
Шумов В.
http://www.acdplus.ru/