Здравствуйте, Sinclair, Вы писали:

V>>Это не таблица движений.
S>Это та самая таблица orders, которая обычно сидит в середине star join

Я хорошо знаю базу Northwind потому что, без ложной скромности, являюсь профи по MS Access. ))

Это не боевая система, в поделках такого уровня десятки таблиц максимум и все твои предыдущие аргументы теряют смысл, если подкреплять их подобными примерами. Тут мне опять не хватает смайлика на сравнимую величину твоей необъективности.

А как организованы настоящие боевые системы, где вообще имеет смысл рассуждать о размерности задач, я уже описывал.
Мы выше обсуждали таблицу движений, а она связана с таблицей ордеров по одному ровно индексу.

В боевой торговой системе примерно такой набор таблиц:

Мovements
 * Document [oo->1] Documents.Id
 * Commodity [oo->1] Commodities.Id
   Amount
 * Сonsignment [oo->1] Сonsignments.Id
 * Subdivision [oo->1] Subdivisions.Id

Тут 4 индекса, индекс {Document, Commodity} наиболее эффективно делать составным и кластерным.
Это таблица на оперемесяц для складского партионного учёта.

Для средневзвешенного учёта вместо Id партии товара указана себестоимость списания (за весь Amount, а не за единицу):

Мovements
 * Document [oo->1] Documents.Id
 * Commodity [oo->1] Commodities.Id
   Amount
   NetCost
 * Subdivision [oo->1] Subdivisions.Id

Тут 3 индекса.

Учёт по средневзвешенной цене более эфективный, если большой "проходняк" одних и тех же товаров.
Если много уникальных товаров, то удобнее партионный учёт.

Другие таблицы выглядят примерно так:

Documents
 * Id
 * ExecutionDate
   SorceDocType [oo->1] DocTypes.Id
   SourceDoc // non-relation Id of the document from different tables
 * Counterparty [oo->1] Counterparties.Id
 * Subdivision [oo->1] Subdivisions.Id

DocTypes
 * Id
   Name
   TableName // не обязательно, эти "знания" могут содержатся в коде обслуживающей программы

Orders
 * Id
   CreationDate
 * Author
   Counterparty
   ...

Основной join по классике master-slave — Documents->Movements.
Ну или два таких join по двум парам таблиц, если приход и расход живут в разных таблицах.
Для сильнонагруженных сценариев (приходы столь же часты как расходы) рекомендуется разделять таблицы прихода и расхода.
Если не разделять, то Amount и NetCost будут со знаком.

Для партионного учёта будет не один, а два join, если интересует не только кол-во, но и финансовая аналитика (нужна партия, в ней хранится цена прихода товара).

Хотя, это ХЗ. Если склад-бухгалтерия составляют одну систему, то по факту фиксации операции создаются соотв. проводки и финансовая аналитика чисто по складу вне бухгалтерии — это уже из разряда "в зубах поковыряться" или "репу почесать", т.е. такую аналитику уже удобней делать по историческим данным и OLAP.