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

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

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

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

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

S>>Какова будет общая схема кода? Или давайте допишем хотя бы схемы таблиц OrderDetails и Consignments — попробую тряхнуть стариной и написать код сам. Вместе посмеёмся потом.

V>Тряхни, какие проблемы?
схемы таблиц OrderDetails и Consignments — в студию. А то вдруг я их неправильно придумаю
V>Обещаю внимательно посмотреть.

V>Э-э-э. Вообще-то 3-я нормальная форма явно требует разрывать транзитивные замыкания, а не создавать их. ))
Так и любой индекс является денормализацией — по определению. Он же вводит "вычисляемые" отношения в чистую реляционную модель. Взрослые люди понимают, что бывают индексы, поддержанные на уровне СУБД, но они не исчерпывают все возможности по оптимизации. Поэтому может потребоваться вводить "рукопашные" индексы, теряя возможность автоматической оптимизации запросов.
Вот, хранение остатков — это один из вариантов такого индекса. Транзитивное замыкание — другой. Нормализация базы нужна не сама по себе (иначе это — культ карго), а для достижения определённых целей.
К сожалению, это мало кто понимает. Вот и возникают всякие идиотизмы типа раздельных полей для улицы/дома в адресе (несмотря на то, что никогда не планируется делать запросов типа "сумма заказов с доставкой на улицу Ленина в любом городе любой страны"), или "код страны — код города — телефон".

V>При пошаговом изменении приходилось после каждого шага править сотни запросов, в т.ч. для отчётов и аналитики.
V>Что такое "пошагово"? — это когда на указанную схему исходник->движения различные типы документов переезжают по-одному.
Я не про перевоз документов. Я про то, что у нас были отчёты, которые строились по актуальным данным. Потом они начали тормозить, и появились идеи "а давайте удвоим уже потраченную стоимость разработки, и всю отчётность перенесём на внешний OLAP сервер, настроив репликацию".
Оказывается, что вполне можно аккуратно проапгрейдить схему базы, почти не трогая клиентов, так, чтобы и отчёты работали, и OLTP летал.
Вот, к примеру, на моей нынешней работе идея "давайте реплицировать данные во внешнюю BI систему" муссируется уже лет пять. Воз и ныне там — оценки стоимости этого решения превышают разумный бюджет, его ежегодно откладывают "на следующий год". С тех пор компания пережила два слияния, одно разделение и одно поглощение — фича по-прежнему в роадмапе.
А под тем предлогом, что "ну это же правильное решение, которое всё равно мы будем делать рано или поздно" существующие отчёты по актуальным данным никто не развивает. Клиенты плачут и жалуются, а лично меня это бесит.
К сожалению, я слишком далёк от той части компании, которая занимается этим вопросом, и сделать ничего не могу. А вот до этого я работал в бодишопе, и к нам регулярно приходили заказы вроде "у нас есть учётная система, она прекрасно работает, кроме вот этих вот пяти мест — можете помочь?". И мы регулярно помогали. При этом без написания целой системы с нуля. Это зачастую вообще невозможно, потому что у мало-мальски развитой системы не существует покрывающей документации. В одну и ту же базу лазят клиенты на Дельфи, джавовский миддл-тиер, и тонна страничек на классическом ASP. А может и ещё что-нибудь, написанное в 1997 году контрактором и давно забытое.
Понять, кто зависит от структуры таблицы SurveyResponses — невозможно, т.к. нет даже способа получить все исходники зависимых систем.
Это означает, что мы принципиально не можем оценить стоимость проекта — может $100k, а может — $1m. "Как пойдёт".
Заказчики почему-то не согласны платить неизвестные заранее деньги и тратить неизвестное заранее время на решение, которое не имеет гарантированных преимуществ.
Поэтому они были очень рады, когда за $30k и две недели им чинили ровно эти пять мест, не ломая ничего из старого кода.