СУБД и деревья

[alexus]

Вот пример исходных данных, и дерева из них построенного.

Хе...хе... в машиностроении/судостроении/самолётостроении... особенно интересно посмотреть на разузлование. И попытку построить такого рода отчёты... Тогда сразу приходит понимание того, что делать надо, а что нет... Возможно и фармацевты к этому придут когда-нибудь... например, внедрив очередные "нано-технологии".

[DIzer]

Но судя по задаче - как ни странно  прав Romiras - она допускает следующее решение
взять весь набор данных с сервера  - в клиентский (индексируемый) дата сет - а приложение пусть аккуратно разбирается с ним -аналог работы с гиперкубом (OLAP- анализ)

Да не нужен здесь OLAP поскольку... нет никакого анализа... а минус - дорогое это решение (и по деньгам, и по времени), да и поддерживать куб в согласованном состоянии, тоже не всегда элементарно.

Я сказал, что ДОПУСКАЕТ = именно по тому, что  работа ведется после того , как внешней процедурой  процедурой по первичке будет произведен перерасчет себестоимости.. а из этого следует, что работа такого рода отчетами периодическая - и производится в конце определенного интервала времени (иначе себестоимость будет иметь выбросы), а значит требование к актуализации данных минимальны - допустимо, например , раз в месяц тратить 20 минут на получение данных, чтобы работать с ними за доли  секунды

[DIzer]

Хм?.. Неожиданно... А не дорого обходится такое решение? Например, если ошибку не выявили, а результаты утвердили (списали в затраты, например, на порядок больше, чем есть на самом деле). Мне кажется, что мухи (баги) должны быть отдельно от котлет (отчётов)... хотя "на вкус и цвет"...

Повторяюсь ,проблема в том, что по данным отчета этого отчета ошибку не выявишь - ибо она входит в данные таблицы -для ее выявления нужно ЧЕСТНО пересчитать себестоимость по первичке и сравнить с этой таблицей

[alexus]

Да не нужен здесь OLAP поскольку... нет никакого анализа... а минус - дорогое это решение (и по деньгам, и по времени), да и поддерживать куб в согласованном состоянии, тоже не всегда элементарно.

Я сказал, что ДОПУСКАЕТ = именно по тому, что  работа ведется после того , как внешней процедурой  процедурой по первичке будет произведен перерасчет себестоимости.. а из этого следует, что работа такого рода отчетами периодическая - и производится в конце определенного интервала времени (иначе себестоимость будет иметь выбросы), а значит требование к актуализации данных минимальны - допустимо, например , раз в месяц тратить 20 минут на получение данных, чтобы работать с ними за доли  секунды

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

[DIzer]

А по смыслу - этот отчет , обычный Олап гиперкуб. А медленно он делается - потому, что исходные данные денормализованы + неудачный первичный  ключ -это приводит к неоправданно большим затратам  при транспортировки данных по сетке и трудности в эффективном построении сечения гиперкуба (разумеется если нет грубейших  ошибок , вроде Select *  from...) .

[alexus]

Хм?.. Неожиданно... А не дорого обходится такое решение? Например, если ошибку не выявили, а результаты утвердили (списали в затраты, например, на порядок больше, чем есть на самом деле). Мне кажется, что мухи (баги) должны быть отдельно от котлет (отчётов)... хотя "на вкус и цвет"...

Повторяюсь ,проблема в том, что по данным отчета этого отчета ошибку не выявишь - ибо она входит в данные таблицы -для ее выявления нужно ЧЕСТНО пересчитать себестоимость по первичке и сравнить с этой таблицей

Вы не внимательно прочитали... Я же не Вам отвечал... Да, и ошибки они разные бывают, бывают ошибки в первичных документах, бывают в запросах, бывают в расчётах... а бывают и в постановке задачи.

[DIzer]

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

Повторяюсь, для СВЕРОЧНЫХ целей этот отчет бессмыслен -но вообще говоря сверка НЕОБХОДИМА  именно потому что в жизни все так хорошо не бывает...

[alexus]

А по смыслу - этот отчет , обычный Олап гиперкуб. А медленно он делается - потому, что исходные данные денормализованы + неудачный первичный  ключ -это приводит к неоправданно большим затратам  при транспортировки данных по сетке и трудности в эффективном построении сечения гиперкуба (разумеется если нет грубейших  ошибок , вроде Select *  from...) .

Так я ещё в самом первом своём сообщении намекнул на проблемы в проектировании...
И если копнуть глубже, то OLAP... это следствие неправильного способа изоляций транзакций В СУБД (при условии правильного проектирования). Почему возникла потребность в OLAP? Потому что аналитические транзакции:
1. Работают медленно (перелопачивают большой объём информации);
2. Требуют высоких уровней изолированности, чтобы анализируемые данные не менялись во время работы транзакции (как минимум repeatable read).
Как следствие, блокировочные СУБД просто "встают колом" и никто не может достучаться до БД. Чтобы этого не происходило, данные сливают в OLAP и там анализируют. Если СУБД поддерживает версионность, то потребность в OLAP значительно снижается. Хотя нормальных версионных серверов просто нет.

[alexus]

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

Повторяюсь, для СВЕРОЧНЫХ целей

Раньше речь шла просто об ошибках... которые бывают разные...

[DIzer]

Да не нужен здесь OLAP поскольку... нет никакого анализа... а минус - дорогое это решение (и по деньгам, и по времени), да и поддерживать куб в согласованном состоянии, тоже не всегда элементарно.

Я сказал, что ДОПУСКАЕТ = именно по тому, что  работа ведется после того , как внешней процедурой  процедурой по первичке будет произведен перерасчет себестоимости.. а из этого следует, что работа такого рода отчетами периодическая - и производится в конце определенного интервала времени (иначе себестоимость будет иметь выбросы), а значит требование к актуализации данных минимальны - допустимо, например , раз в месяц тратить 20 минут на получение данных, чтобы работать с ними за доли  секунды

И если копнуть глубже, то OLAP... это следствие неправильного способа изоляций транзакций В СУБД (при условии правильного проектирования). Почему возникла потребность в OLAP? Потому что аналитические транзакции:
1. Работают медленно (перелопачивают большой объём информации);
2. Требуют высоких уровней изолированности, чтобы анализируемые данные не менялись во время работы транзакции (как минимум repeatable read).
Как следствие, блокировочные СУБД просто "встают колом" и никто не может достучаться до БД. Чтобы этого не происходило, данные сливают в OLAP и там анализируют. Если СУБД поддерживает версионность, то потребность в OLAP значительно снижается. Хотя нормальных версионных серверов просто нет.

1. На деле оказалось - что они ничего не проектируют - просто в  тупую работают с неудачно сформированными (не ими !!!) данными.
2. Олап это прежде всего следствие отсутствия  релевантных моделей анализа - и цель его - помощь в формирования оных.
3. А я еще не видел универсальные решения спроектированный без bottlenecks - в условиях когда меняются модели анализа.
4. Лично я работал в основном с версионниками.. но там есть свои заморочки.. база пухнет как на дрожжах, дополнительные усилия на логгирование (если есть необходимость в многоуровневых откатах)...

[adva]

Предположим, что таблица имеет примерно такую структуру:
1. Показатель; (первичный ключ) [INDICATOR];
2. Ссылка на показатель верхнего уровня (внешний ключ, может быть null для корневых узлов) [OWNER_INDICATOR];
3. Единицы измерения [UNIT];
4. Значение показателя в натуральном выражении (объём/количество) [VAL_NATURAL];
5. Значение показателя в денежном выражении [VAL_CURRENCY].

Примечания:
А) если одна ветка иерархии входит в несколько веток, то есть, записи таблицы ссылаются на другие записи той же таблицы в отношении многие-ко-многим, то нужна ещё таблица для ссылок;
Б) более оптимальное (правильное) решение состоит в том, что структура показателей хранится отдельно от значений показателей.

При данной структуре таблицы надо иметь всего один параметризуемый запрос, чтобы вывести нужный показатель:

Код: [Выделить]

SELECT "INDICATOR", "UNIT", "VAL_NATURAL", "VAL_CURRENCY" FROM "MY_TABLE" WHERE "OWNER_INDICATOR" = :OIND;Когда пользователь "щёлкает" на каком-то показателе, подставляем его идентификатор в запрос, получаем данные и выводим на экран. Происходит это очень быстро (как правило, миллисекунды для тысяч записей), поскольку по внешнему ключу [по умолчанию] создаётся индекс.

Можно более подробно про отдельную структуру показателей? Какая у нее таблица? Я так понимаю, можно выполнить до формирования отчета преобразование вышеописанной таблицы в 2 другие. Но не понял, как можно будет связать таблицу структуры и таблицу показателей?

[ilovb]

1. На деле оказалось - что они ничего не проектируют - просто в  тупую работают с неудачно сформированными (не ими !!!) данными.

Я уже говорил: Эта таблица для других целей оптимизирована. (и вполне удачно для своих целей) Структуру ее мы менять не можем, т.к. на нее завязано много тысяч строк кода.

Таблица такая какая есть, и точка. Нужно очень много времени, чтобы объяснить почему у нее такая структура.

Какой смысл рассуждать о ее структуре?

[ilovb]

Можно более подробно про отдельную структуру показателей?

Ага. Я вот тоже секрет alexus'а понять не могу. 

[alexus]

1. На деле оказалось - что они ничего не проектируют - просто в  тупую работают с неудачно сформированными (не ими !!!) данными.

Об этом и речь...

2. Олап это прежде всего следствие отсутствия  релевантных моделей анализа - и цель его - помощь в формирования оных.

То есть, всё тот же недостаток проектирования, неверно сформированы модели предметной области.

3. А я еще не видел универсальные решения спроектированный без bottlenecks - в условиях когда меняются модели анализа.

А с чего им меняться?.. Аналитических плоскостей не так уж много...

4. Лично я работал в основном с версионниками.. но там есть свои заморочки.. база пухнет как на дрожжах, дополнительные усилия на логгирование (если есть необходимость в многоуровневых откатах)...

Речь видимо про Firebird или Interbase... С чего бы у версионных СУБД база "пухла"?.. Старые версии не хранятся дольше, чем к ним есть интерес. Отсутствие журнала - это не проблема версионных СУБД, а конкретной реализации (всё тот же Firebird). Для откатов (многоуровневых, в том числе) можно использовать save points, но, конечно, в рамках текущей транзакции. Если выходить за пределы транзакции, то нужна поддержка журнала, разработчикам Firebird об этом говорят лет 20... может быть и больше (я про то, что за время моей работы с этой СУБД знаю).

[DIzer]

1. На деле оказалось - что они ничего не проектируют - просто в  тупую работают с неудачно сформированными (не ими !!!) данными.

Я уже говорил: Эта таблица для других целей оптимизирована. (и вполне удачно для своих целей) Структуру ее мы менять не можем, т.к. на нее завязано много тысяч строк кода.

Таблица такая какая есть, и точка. Нужно очень много времени, чтобы объяснить почему у нее такая структура.

Какой смысл рассуждать о ее структуре?

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