Re[55]: В России опять напишут новый объектно-ориентированны
От: vdimas Россия  
Дата: 10.07.18 13:21
Оценка:
Здравствуйте, Sinclair, Вы писали:

V>>Не "лишнюю", а "единственную".

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

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


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


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


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


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


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

S>Именно по ним и гоняется.

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


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


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

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


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


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


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


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

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

Т.е., если изнасиловать доменную модель по предлагаемому тобой варианту, то сразу огребаем в затратах на ручном обслуживании эмулируемой доменной модели внутри "нейтрального" к домену агрегата. ))
Отредактировано 10.07.2018 13:34 vdimas . Предыдущая версия .
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.