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

V>>Не "лишнюю", а "единственную".
V>>Я задавал прямой вопрос — "сколько таких таблиц в базе?"
S>Опять за рыбу деньги. Ок, мы добавили в базу одну таблицу, по которой есть два индекса и полтора плана..
S>Это никак не меняет ситуацию — остальные таблицы как были, так и остались, и запросы по ним как были, так и остались.

Индексов зато на порядок меньше.

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

V>>Не "лишнюю", а "единственную".
V>>Я задавал прямой вопрос — "сколько таких таблиц в базе?"
S>Опять за рыбу деньги. Ок, мы добавили в базу одну таблицу, по которой есть два индекса и полтора плана..
S>Это никак не меняет ситуацию — остальные таблицы как были, так и остались, и запросы по ним как были, так и остались.

Индексов зато на порядок меньше.


S>И как раз по этим таблицам никаких запросов не гоняется.

Как раз по этим таблицам и гоняется.


S>Зачем их вообще обсуждать?

Тебе неудобно?


V>>По "исходникам" никакая аналитика не гоняется.
S>Именно по ним и гоняется.

В наколенных поделках разве что.


S>Потому что в "движениях" уже никакой аналитики нету.

Тут нужен пример такой востребованной аналитики, что нужны исходники док-тов.

Потому что в промышленных системах бывает даже еще более циничный подход: вот прямо в той таблице Documents всё и хранится.
Просто есть еще 3-4 slave-таблицы с т.н. "аттрибутами", для хранения доп. полей, которые не вошли в дефолтную разметку таблицы Documents.
Как думаешь, зачем так делают?


S>Мне она вообще не интересна — отчётов, в которых нужно вместе учитывать и заказы и акты инвентаризации, в реальном бизнесе не бывает.

ОМГ ))
В той таблице хранится среди прочего тип док-та, разумеется.
И весь необходимый набор полей для 99% всей требуемой оперативной аналитики (по текущему периоду).


S>Отчёты строятся ровно по тем самым заказам, ровно одного вида, который интересует.

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

Если же сводить все типы заказов к одной таблице, то мы получим огромной ширины избыточный агрегат, который в большинстве полей хранит просто NULL.
Опять же, код валидации превращается в ад и Израиль (С), бо для некоторых типов заказов некоторые поля из такой "объединённой таблицы" могут быть NULL, какие-то нет и т.д. и т.п.

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