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

V>>Или ты опять предлагаешь при добавлении нового типа документа скакать по всей базе в поисках зависимостей? ))
S>Я вообще ничего про "скакать" не предлагаю. Это вы пытаетесь от неудобной для вас темы планов запросов перейти к вопросам дизайна базы.
V>>Да я уже понял, что ты хотел на досуге поиграть с показанной схемой... хотел, хотел... но обломался.
S> Я поиграл, но понял, что это был ложный манёвр — внести в обсуждение лишнюю таблицу.

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


S>В реальности всё упирается в orders и orderDetails

Бог с тобой.
В реальности видов orders многие десятки, иногда больше сотни.
Каждый из них живёт в своей уникальной таблице.
Т.е. умножай на сотню сходу.


S>и мы возвращаемся к исходной точке — в классических примерах там 8 индексов

В таблице movements 3 индекса в классике (один составной).
В таблице documents — зависит от.
Ну пусть даже 5-6.
Эти таблицы единственные в своём роде.
Практически все остальные данные имеют справочный характер (кроме "исходников" документов).
По "исходникам" никакая аналитика не гоняется.

Кароч, всё это страшно далеко от "сотен таблиц с 15-ю индексами в каждой" (С)


S>и ровно потому, что по этой таблице строятся аналитические отчёты.

Которые в показанной промышленной схеме строятся минимум на порядок быстрее, чем в случае собирания аналитики из сотен таблиц в ваших наколенных поделках.
В том числе потому, что трудоёмкость составления всех планов в сотню раз меньше.


S>Когда вы начнёте делать такие же отчёты по таблице движений, то придётся добавить те же индексы, и вводить в рассмотрение те же планы.

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

При этом, сей набор планов один и тот же для нескольких сотен (или тысяч) всевозможнейших отчётов по аналитике.
Это ПРОСТЕЙШУЮ мысль я не могу донести до тебя уже пол-года.


S>И хрен вы построите "один, оптимальный план" по историческим данным — тупо потому, что "оптимальность" плана зависит от значений параметров.

Но к сегодняшнему дню ты хоть понял, почему код оценки плана растёт от листьев к корню или еще нет? ))
И почему на выходе получается не полное мн-во всех перестановок, а гораздо ближе к простой сумме всех индексов?

Т.е. понимаешь ли ту простую весчь, что если даже к основному join добавили некоторый join со справочными данными и даже если выгодней сначала ограничить выборку через справочник (у которого есть только суррогатный ключ), то код оценки трудоёмкости скана по этому основному join будет тот же? И что код выборки тоже будет тот же, бо у нас есть лишь два варианта — сначала сканить таблицу движений или сначала таблицу документов.


S>А они, в отличие от исторических данных, каждый раз разные.

Зато код оценки планов и скана таблиц один и тот же.
Что и требовалось.

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

V>>Или ты опять предлагаешь при добавлении нового типа документа скакать по всей базе в поисках зависимостей? ))
S>Я вообще ничего про "скакать" не предлагаю. Это вы пытаетесь от неудобной для вас темы планов запросов перейти к вопросам дизайна базы.
V>>Да я уже понял, что ты хотел на досуге поиграть с показанной схемой... хотел, хотел... но обломался.
S> Я поиграл, но понял, что это был ложный манёвр — внести в обсуждение лишнюю таблицу.

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


S>В реальности всё упирается в orders и orderDetails

Бог с тобой.
В реальности видов orders многие десятки, иногда больше сотни.
Каждый из них живёт в своей уникальной таблице.
Т.е. умножай на сотню сходу.


S>и мы возвращаемся к исходной точке — в классических примерах там 8 индексов

В таблице movements 3 индекса в классике (один составной).
В таблице documents — зависит от.
Ну пусть даже 5-6.
Эти таблицы единственные в своём роде.
Практически все остальные данные имеют справочный характер (кроме "исходников" документов).
По "исходникам" никакая аналитика не гоняется.

Кароч, всё это страшно далеко от "сотен таблиц с 15-ю индексами в каждой" (С)


S>и ровно потому, что по этой таблице строятся аналитические отчёты.

Которые в показанной промышленной схеме строятся минимум на порядок быстрее, чем в случае собирания аналитики из сотен таблиц в ваших наколенных поделках.
В том числе потому, что трудоёмкость оценки всех планов в сотню раз меньше.


S>Когда вы начнёте делать такие же отчёты по таблице движений, то придётся добавить те же индексы, и вводить в рассмотрение те же планы.

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

При этом, сей набор планов один и тот же для нескольких сотен (или тысяч) всевозможнейших отчётов по аналитике.
Это ПРОСТЕЙШУЮ мысль я не могу донести до тебя уже пол-года.


S>И хрен вы построите "один, оптимальный план" по историческим данным — тупо потому, что "оптимальность" плана зависит от значений параметров.

Но к сегодняшнему дню ты хоть понял, почему код оценки плана растёт от листьев к корню или еще нет? ))
И почему на выходе получается не полное мн-во всех перестановок, а гораздо ближе к простой сумме всех индексов?

Т.е. понимаешь ли ту простую весчь, что если даже к основному join добавили некоторый join со справочными данными и даже если выгодней сначала ограничить выборку через справочник (у которого есть только суррогатный ключ), то код оценки трудоёмкости скана по этому основному join будет тот же? И что код выборки тоже будет тот же, бо у нас есть лишь два варианта — сначала сканить таблицу движений или сначала таблицу документов.


S>А они, в отличие от исторических данных, каждый раз разные.

Зато код оценки планов и скана таблиц один и тот же.
Что и требовалось.