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

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

В мире многое чего происходит не благодаря, а вопреки. ))

И воровство при такой организации "учёта" обычно цветёт и пахнет, потому что достаточно поменять строчки заказа (цену в них или кол-во) и вся отчётность автоматом "плывёт". Разницу можно себе в карман. Наблюдал более 3-х раз вживую.

Или тут рядом говорили о 10 гигах в логе, забыли сказать — за какой период.


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

Отчет раз в месяц по read-only данным?
После закрытия периода и подведения итогов?


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

Я тут неверно выразился.
Нет суррогатного уникального ключа.
Чтобы гарантиоровать что-то там по суррогату сначала надо определиться — а нужен ли сам суррогат?


S>Вопрос риторический, можно не отвечать.

Вопрос не риторический, а жульнический.

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

Кароч, есть несколько схем раздачи уникальных ключей и без механизма базы. Более того, почти всегда необходимо знать значение уникального суррогатного ключа еще до вставки. Это если мы всё еще об эффективности. Потому что в наколенных поделиях, разумеется, можно и узнать значение такого ключа уже после вставки, но я бы бил линейкой по пальцам, если бы речь шла о чём-то более-менее серьёзном.

Тема вообще смешная, кста. По-факту в тех самых "реальных системах" я наблюдал не раз обеспечение уникальности суррогатных ключаей в тех местах, где этого не требовалось. Не потому не требовалось что, мол, и без базы сами обеспечим, а потому что она там не нужна прямо согласно предметной области. Сам суррогатный ключ не требовался.

И это речь о тех самых "квалифицированных DBA", которые хорошо умеют тюнить имеющуюся схему, но плохо понимают, почему эта схема именно такая. Да и, положа руку на сердце, грамотно раскидать данные по таблицам — во все времена было исскуством. Northiwind в этом смысле тот самый Ад и Израиль. (С)

Популярные в начале 2000-х руководства и куча инструментария по доменному моделированию предметных областей приводили к рождению монстров. Потому что не может непрофессионал заниматься разработкой схемы хранения данных.

А любой DBA — это непрофессионал от IT, эдакий гастарбайтер, — такое железное правило сложилось как раз в 90-2000-х годах и вовсе не только на просторах СНГ, в Штатах ровно аналогично. Всё из-за программистских зарплат. Причём, даже если чел имеет IT-образование, но как "честный программист" не удался, то хватается или за HTML или за DBA. Это та самая классика жанра.

В этом смысле дотнет, помнится, натурально спас всю эту прослойку, бо позволил утилизировать её в виде, таки, снова программистов, а не только лишь обслуги имеющегося софта.

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

IT до сих пор, заметь, больно бъет за попытки мыслить слишком абстрактно.
Особенно это стало заметно из-за мобильного сегмента, где эффективность опять в цене.


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

Тряхни, какие проблемы?
Обещаю внимательно посмотреть.


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

Э-э-э. Вообще-то 3-я нормальная форма явно требует разрывать транзитивные замыкания, а не создавать их. ))
Это всё еще про tradeoff между нормализацией и денормализацией.
Т.е., порой никуда от избыточности не денешься.


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

Не верю.

Поясню.
При пошаговом изменении приходилось после каждого шага править сотни запросов, в т.ч. для отчётов и аналитики.

Что такое "пошагово"? — это когда на указанную схему исходник->движения различные типы документов переезжают по-одному.
Дешевле оказалось перевести все документы сразу и тем самым переписать сотни запросов лишь однажды.
Я просто измерил скорость и увидел, что требуется около года на пошаговый переезд. Для переезда с 0-ля мне хватило пары месяцев.

Понятно, что было очень много чего переиспользовано из уже готовой системы (отчёты, контролы, формы, хелперы и т.д.). Но схема данных была раздизайнена с 0-ля и она оказалась весьма живучей, в том плане, что на её основе была сделана куча модификаций для разных специфик.

Т.е. оказалось дешевле переписать всё с 0-ля и подготовить скрипты импорта из живой системы. В один прекрасный день данные просто переехали на новую систему.