Здравствуйте, vdimas, Вы писали:
V>ИМХО, это наколенные поделки, разросшиеся до больших масштабов.
V>Пару раз я и такое видел, и?
И отлично работает в продакшне. Особенно если пригласить компетентного DBA с пониманием того, как сервер

S>>Очень удобно — вместо разговоров о таблице orders, поговорим о таблице Movements.

V>Именно так. Удобно.
V>Потому что тяжеловесное обращение к Orders относительно "однократное" — в момент проводки.
Это если нам неинтересны ордера. Как правило, как раз интересны — всякие отчёты типа "сравнить работу менеджера по продажам в текущем месяце с предыдущим" и прочие — они ж не по таблице движений будут делаться.
Ну, отложим пока в сторонку.


V>Через "чистую реляцию" никак не связаны, насколько ты успел понять (надеюсь).
V>В рамках транзакции меняется состояние док-та из Orders и появляется, либо исчезают строки из Documents и Movements.
Отлично, отлично.

S>>2. Как мы гарантируем, что у Movement и его Document совпадают Subdivision?

V>Да там не только это надо гарантировать.
V>Начинать надо с DocumentId.
V>Твой вопрос более общий: как гарантировать целостность данных в условиях избыточности или отсутствия связей, гарантирующих целостность данных?
V>Известное решение одно — транзакции.



S>>3. Как выглядит код "отгрузки заказа"? Я же правильно понимаю, что мы должны из Order и его OrderDetails породить Document и Movements, одновременно подправив значения остатков в соответствующих Consignments?
V>Именно так.
Давайте закопаемся в детали.

V>Заметь, что в таблице движений нет уникального ключа.
V>Уникальные ключи тоже зло и тормоза, увы.
Ухтыжблин! А что, есть какой-то более быстрый способ гарантировать уникальность? Вопрос риторический, можно не отвечать.

V>"Полуаналитика" тоже нужна. Например, у меня была таблица "товары на резерве".
Вот я как раз про это.
V>Т.е. вот десятки девочек выписывают накладные, они видят в каждой строке одни и те же остатки.
V>В наивном виде это будут остатки по факту проводки документов, а для целей выписки нужны остатки с учётом выписываемого за соседним столом в ту же секунду.
Да-да-да. Ну, давайте хотя бы процедуру отгрузки ордера набросаем, посмотрим, как она будет устроена, и будут ли нам индексы мешать или помогать.
Потом добавим расчёт "мгновенных остатков" с учётом заказов в статусах "пред-резерв". А потом уже будем смотреть, что можно накрутить без особой потери производительности.
Какова будет общая схема кода? Или давайте допишем хотя бы схемы таблиц OrderDetails и Consignments — попробую тряхнуть стариной и написать код сам. Вместе посмеёмся потом.

V>Например, мой любимый способ представления иерархических данных строг и шустр, хоть и избыточен.
V>(связь от каждого узла к каждому Parent+расстояние)
Это называется "транзитивное замыкание", и не "изобрёл" его только ленивый.


V>Так нельзя.
V>У меня не получилось, только время потратил в кол-ве 2-х месяцев траха.
У меня — получалось.