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

V>>Индексов зато на порядок меньше.
S>С чего бы?

С ненужности.
Доп. поля в документах-исходниках в 90% случаев не нужны для аналитики, поэтому по ним нет ограничений и нет индексов.


V>>Как раз по этим таблицам и гоняется.
S>Всё, я потерял нить рассуждений.

Отож.


S>Как устроена база? В ней что, осталось три таблицы, по которым и гоняются все запросы?

По которым гоняется львиная доля вызываемых запросов.

В остальных таблицах среднее кол-во индексов приближается к 2-м от силы.


V>>Тебе неудобно?
S>Нет, просто доказать тезис "индексы не нужны" путём добавления в рассмотрение ещё одной таблицы, в которой достаточно двух индексов, не получится.

Уже получилось.


V>>Тут нужен пример такой востребованной аналитики, что нужны исходники док-тов.
S>Я, возможно, не понимаю термина "исходники". Чем они отличаются от самих документов?
S>Примеры аналитики я привёл — каждой службе интересно что-то своё.

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

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

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

С твоим подходом "каждому документу по таблице, каждой таблице по 15 индексов" это всё не взлетело бы низачто и никогда. ))


V>>В той таблице хранится среди прочего тип док-та, разумеется.
V>>И весь необходимый набор полей для 99% всей требуемой оперативной аналитики (по текущему периоду).
S>Что-то мне подсказывает, что в угаре спора сейчас кто-то изобретёт схему E-A-V имени Тенцера.

Что-то мне подсказывает, что достаточно подробностей я дал еще кучу постов подряд.
Там основные поля указаны, разрешаю освежить инфу перед следующим раундом.


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



S>И при этом всё ещё будут интересны в рамках какого-то одного отчёта.

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

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

А ты предлагаешь и от доменной модели отказаться, устроив из таблиц свалку и профита никакого взамен не дал.
Твои предложения бессмысленны более чем полностью, и не только не имеют технической ценности, но просто вредны: усложняют разработку и поддержку, резко просаживают производительность.
Добавить новый тип документа? — это переписать пол-базы.
Посчитать аналитику? — не забыть пройтись по сотне таблиц с 15-ю индексами в каждой (С).

Это всё нерабочие схемы.
Да, я помню, что ты хвастался тем, что ЗАСТАВЛЯЛ такие схемы работать.
Но это всё write-only.
Один раз написать и всю жизнь молиться. ))
Костяка нет, всё рыхлое, в каждой группе сущностей собственные произвольные правила/наработки.
При столкновении с реальностью, в которой нужно постоянно что-то допиливать сугубо из-за прикладных нужд, оно всё сыпется как карточный домик.

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

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

V>>Индексов зато на порядок меньше.
S>С чего бы?

С ненужности.
Доп. поля в документах-исходниках в 90% случаев не нужны для аналитики, поэтому по ним нет ограничений и нет индексов.


V>>Как раз по этим таблицам и гоняется.
S>Всё, я потерял нить рассуждений.

Отож.


S>Как устроена база? В ней что, осталось три таблицы, по которым и гоняются все запросы?

По которым гоняется львиная доля вызываемых запросов.

В остальных таблицах среднее кол-во индексов приближается к 2-м от силы.


V>>Тебе неудобно?
S>Нет, просто доказать тезис "индексы не нужны" путём добавления в рассмотрение ещё одной таблицы, в которой достаточно двух индексов, не получится.

Уже получилось.


V>>Тут нужен пример такой востребованной аналитики, что нужны исходники док-тов.
S>Я, возможно, не понимаю термина "исходники". Чем они отличаются от самих документов?
S>Примеры аналитики я привёл — каждой службе интересно что-то своё.

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

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

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

С твоим подходом "каждому документу по таблице, каждой таблице по 15 индексов" это всё не взлетело бы низачто и никогда. ))


V>>В той таблице хранится среди прочего тип док-та, разумеется.
V>>И весь необходимый набор полей для 99% всей требуемой оперативной аналитики (по текущему периоду).
S>Что-то мне подсказывает, что в угаре спора сейчас кто-то изобретёт схему E-A-V имени Тенцера.

Что-то мне подсказывает, что достаточно подробностей я дал еще кучу постов назад.
Там основные поля указаны, разрешаю освежить инфу перед следующим раундом.


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



S>И при этом всё ещё будут интересны в рамках какого-то одного отчёта.

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

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

А ты предлагаешь и от доменной модели отказаться, устроив из таблиц свалку и профита никакого взамен не дал.
Твои предложения бессмысленны более чем полностью, и не только не имеют технической ценности, но просто вредны: усложняют разработку и поддержку, резко просаживают производительность.
Добавить новый тип документа? — это переписать пол-базы.
Посчитать аналитику? — не забыть пройтись по сотне таблиц с 15-ю индексами в каждой (С).

Это всё нерабочие схемы.
Да, я помню, что ты хвастался тем, что ЗАСТАВЛЯЛ такие схемы работать.
Но это всё write-only.
Один раз написать и всю жизнь молиться. ))
Костяка нет, всё рыхлое, в каждой группе сущностей собственные произвольные правила/наработки.
При столкновении с реальностью, в которой нужно постоянно что-то допиливать сугубо из-за прикладных нужд, оно всё сыпется как карточный домик.

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