Понимаю, что на тему остатков уже писано-переписано, но тем не менее это вечно живая тема... :)
У кого какой опыт по проектированию/получению Sabj ?
Обязательные условия:
- огромный товарооборот и удовлетворительная производительность;
- хранение всех операций не менее, чем за год;
- партионный мультискладовый учёт;
- возможность получения остатков на любую дату и по любой комбинации складов;
- возможность урезки базы без потери правильности данных за открытый период;
- возможность прихода/продажи задним числом.

Мой опыт:

В основе две таблицы:
Товарный журнал со всеми операциями (упрощенно) : Operation_ID, Document_ID, OperationTypeID, OperationDate, ItemID, AdrFromID, AdrToID, Qty, Summ
где: Document_ID -номер документа OperationTypeID- тип операции(покупка,продажа,списание и т.п.)
AdrFromID, AdrToID откуда/куда делается операция (поставщик-склад, склад-склад, склад-клиент и т.п.)
Qty, Summ - знак в зависимости от операции - расход с минусом, приход с плюсом

Журнал промежуточных итогов (подИтогов):
TotalDate, ItemID, AdrID, Qty, Summ
где: TotalDate - дата на которую посчитан подИтог, AdrID - склад

Расчёт остатков - сумма ближайшего промежуточного итога и сумма операций по журналу по (дата) between (ближ.промеж.дата+1) and (нужная дата)
Использую union и агрегатную сумму по его результату :)
Промежуточные остатки можно делать, например 1-2 раза в месяц.
Применения между приходами и расходами (для парт.учёта) лежат в отдельной таблице, которую пока не будем рассматривать.
В любой момент базу можно урезать, но желательно по OperationDate не позднее самого раннего подИтога.
Наблюдается сильная зависимость производительности от удаленности даты до ближайшего подИтога
(если 2дня итог 2-3сек для 40тыс. товара, если 30дней, то 11-14 сек. Это всё для >4млн. операций за 10мес. сервер 2x2.4HHz 2Gb RAM)

Недостатки : невысокая производительность (частые Index Scan) :(
Вот собственно всё...
КТО КАК ЭТО ДАЛАЕТ ?
Есть подозрение, что сделать оптимальнее без потери функциональности не удастся.... :(
А ВАШЕ МНЕНИЕ ? :)

забыл добавить требование:
- необходимо получать данные одним запросом и желательно без подзапросов.

Это важно при получении отчетности внешними средствами. Может требование и необязательное, но желательное.
В описании желательно приводить временнЫе результаты Ваших решений ...типа как у меня... :)

2 Александр Спелицин
Речь идет не о повышении производительности конкретного сервера.
Нужно, чтоб структура работала пошустрее... :)

самое главное опять забыл: MSSQL2000EE
хотя это не очень-то важно. Важно САМО РЕШЕНИЕ вне зависимости от платформы.

2 Александр Спелицин

Уйти ? Я бы с радостью.. А как ? Надо независимо просуммировать операции в двух таблицах и сложить полученные результаты. Причем в любой из них может не быть результата по нужным условиям (например когда "нужая дата"=ДатаПодИтога не будет данных в запросе по Товарному журналу).

также не вижу возможности использовать индексированные вью.... :)
Не помогут они, ИМХО...
Спасибо за советы по настройкам сервера, но это увы неактуально т.к. это не prodaction DB. Это пока development :)
А prodaction может работать и на простеньких серверах с простым IDE-зеркалом :) Например небольшой могазин.. :)

автор бОльшая часть запросов скорее всего на текущие остатки
:) БОльшая это ещё не 100% :)

Кстати такая табличка есть... Она ещё резервирование товара показывает.
Правда меняется при проводке документа... Но это отдельный разговор.
важно иметь не просто остатки, но ещё и все (!) перемещения товара.
А вот перемещения смотрят постоянно и все кому не лень... :(
Для этого и товарный журнал с 4млн строк... :)

2 Серега

:) Ну что сказать ?... Не знаком человек с розничной торговлей... :)
Перемещения товара смотрят часто и тут ничего не поделаешь...
Зачем нужны остатки на дату в прошлом ? Как это зачем ?
Например сверка с поставщиком на определённую дату, т.е. сколько оставалось его товара и сколько ему заплатить за уже проданое.
Не говоря уже про разборы полётов при оприходовании или отпуске ... :)
А констрейнтами не борятся с отрицательными остатками ! ! !
Потому, что есть ситуации когда отрицалово допустимо (в разумных пределах)

2 Old Nick

как раз хранение типа и даты операции в товарном журнале хоть и увеличивает размер таблицы, но заметно ускоряет запросы по статистике.
Намного ускоряет ! В разы ! Это тоже проверено !
Как можно в запросе делать ссылку на документы, если они разбросаны по разным таблицам ? Применять CASE ? Тогда наверняка будет Table scan.
Тем более для остатков тип документа как раз и не важен :) Важна сумма всех операций... :)
Повторю: Задача не только получить остатки на дату. Задача - получить универсальный функционал для работы с товаром.
Предложеное мной решение может и не оптимальное, но ИМХО наиболее близкое к желаемому...По крайней мере по функциональности...

2 Серега
>> Где собирают ? куда ? ....

Например скоропорт может быть продан раньше, чем оприходуют. И эта разница может составлять во времени всего полчаса... :)
Часто приходуют утром вечерние поставки, а товар уже почти продан :)
Не надо рассказывать про бардак ! Он в рознице неизбежен, хотя масштабы его должны быть незначительны. :) :) :)

Кстати полностью согласен с olk ! Понимает человек, о чём идёт речь ! ! !

Что-то в топике почти нет конструктивных советов и своих примеров решения затронутой проблемы... :(
Все хранят свои тайны ? ? ?
Зато желающих похаять что-либо или вставить свои 5коп. не в тему (зарисоваться) хоть отбавляй... :(
Опять забыли, что обсуждаем и перешли на личности ? Несолидно, коллеги ! ! !

ВОПРОС И УСЛОВИЯ ПОСТАВЛЕНЫ ОЧЕНЬ ЧЁТКО.
Просьба приводить ТОЛЬКО ПРОВЕРЕННЫЕ РЕШЕНИЯ И ТОЛЬКО ЕСЛИ ВЫПОЛНЯЕТСЯ ХОТЯ-БЫ БОЛЬШАЯ ЧАСТЬ НАЧАЛЬНЫХ УСЛОВИЙ !