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

S>Здравствуйте, vdimas, Вы писали:
V>>Дык, ты же спорил против отдельных таблиц для движений.
V>>Я приводил аргументы насчёт раздельно настраиваемых прав доступа в качестве дополнительных для схемы с отдельными таблицами движений.
S>Нет. Изначально я спорил насчёт того, что таблица "движений" является самой высоконагруженной. Вы, коллега, решили сместить тему обсуждения, чтобы избежать вопросов построения планов запросов по как раз нагруженным таблицам orderDetail и Orders, на специальную отдельную таблицу движений, которая дублирует OrderDetails.
S>При этом эта таблица, естественно, является слабонагруженной — основной вид запросов в неё это insert

Подмена понятий.
Операция вставки является "слабонагруженной", а не таблица.
Но в этом и была цель, собсно.

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


S>и там, действительно, все интересные планы можно один раз прописать заранее.

Дык, я именно об этом с самого начала и говорил — что по таблице движений кол-во планов запросов априори невелико.
Это если брать оперативные данные.
А если брать исторические, т.е. неизменяемые, то таким данным можно поставить атрибут "read only" и тогда для львиной доли сценариев уже в compile-time можно найти не просто "всевозможные планы", а именно лучшие или даже один лучший. Данные-то уже все есть.

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


S>А вся краткосрочная аналитика делается по orderDetail и Orders

Русским языком было написано про "товары на резерве".
Разумеется, это тоже одна таблица на десятки возможных типов документов.
Или ты опять предлагаешь при добавлении нового типа документа скакать по всей базе в поисках зависимостей? ))


S>ровно как в той самой схеме Northwind, которую вы пытались критиковать.

Да я уже понял, что ты хотел на досуге поиграть с показанной схемой... хотел, хотел... но обломался.



S>Если что-то продолжает оставаться непонятным — спрашивайте, я поясню.

Да всё понятно, хосподя.

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

S>Здравствуйте, vdimas, Вы писали:
V>>Дык, ты же спорил против отдельных таблиц для движений.
V>>Я приводил аргументы насчёт раздельно настраиваемых прав доступа в качестве дополнительных для схемы с отдельными таблицами движений.
S>Нет. Изначально я спорил насчёт того, что таблица "движений" является самой высоконагруженной. Вы, коллега, решили сместить тему обсуждения, чтобы избежать вопросов построения планов запросов по как раз нагруженным таблицам orderDetail и Orders, на специальную отдельную таблицу движений, которая дублирует OrderDetails.
S>При этом эта таблица, естественно, является слабонагруженной — основной вид запросов в неё это insert

Подмена понятий.
Операция вставки является "слабонагруженной", а не таблица.
Но в этом и была цель, собсно.

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


S>и там, действительно, все интересные планы можно один раз прописать заранее.

Дык, я именно об этом с самого начала и говорил — что по таблице движений кол-во планов запросов априори невелико.
Это если брать оперативные данные.
А если брать исторические, т.е. неизменяемые, то таким данным можно поставить атрибут "read only" и тогда для львиной доли сценариев уже в compile-time можно найти не просто "всевозможные планы", а именно лучшие или даже один лучший. Данные-то уже все есть.

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


S>А вся краткосрочная аналитика делается по orderDetail и Orders

Русским языком было написано про "товары на резерве".
Разумеется, это тоже одна таблица на десятки возможных типов документов.
Или ты опять предлагаешь при добавлении нового типа документа скакать по всей базе в поисках зависимостей? ))


S>ровно как в той самой схеме Northwind, которую вы пытались критиковать.

Да я уже понял, что ты хотел на досуге поиграть с показанной схемой... хотел, хотел... но обломался.



S>Если что-то продолжает оставаться непонятным — спрашивайте, я поясню.

Да всё понятно, хосподя.