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

[DIzer]

Но нам нужна ведь не вся таблица. А только то что входит в наше дерево. Мы например сделали отбор по одному виду продукции. Т.е. из 10м строк в разузловании будут учавствовать только 500 например.
Но вы не можете получить одним запросом эти 500 строк, т.к. вам не известна глубина дерева!!!

  Почему- разве в таблице не хранится идентификатор обьекта учета? если нет,  то нужно вставлять...  и делать по нему индекс

[DIzer]

я про то, что данные в ЭТУ таблицу могут заносится некорректно , например, не полностью в следствии некорректного учета первичных документов (из которых рассчитываются затраты)

Так вот отчет для того и нужен в частности. Чтобы выявлять ошибки.

а каким образом вы по нему сможете выявить ошибку такого рода?

[ilovb]

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

[DIzer]

Почему- разве в таблице не хранится идентификатор обьекта учета? если нет,  то нужно вставлять...  и делать по нему индекс

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

[ilovb]

Блин у стола лак забыл разузловать.
Но я думаю суть понятна. 

[DIzer]

... в этом случае вы сможете делать очень эффективные срезы данных , а на них в свою очередь делать деревья (точнее представлять данные содержащиеся в срезах в виде древовидной структуры) или дополнительную фильтрацию
...
... да я понял

[valexey]

Блин у стола лак забыл разузловать.
Но я думаю суть понятна. 

Да, понятно. Результирующая структура данных сильно смахивает на кучу.

[alexus]

DIzer посмотрите личное сообщение 

alexus, вам тоже пытаюсь послать.

Посмотрел. Обычный "бухгалтерский отчёт" по затратам. К задачам управления предприятием он имеет оооочень косвенное отношение. Такие отчёты обычно создаются, когда нет нормального учёта и хоть какую-то информацию, хоть каким-то способом... пытаются вытянуть из бухгалтерии. Для этого в бухгалтерию начинают сливать огромное количество самой разной информации, например данный из КД (конструкторской документации). По всей видимости, это Ваш случай... термин "разузлование", которым Вы пользуйтесь, - взят именно оттуда... из КД.
Не подумайте, что я критикую данное решение (хотя, конечно, приветствовать я его не могу), но... нелепый отчёт порождает нелепые требования... к ресурсам. Всё нормально.
Почему это "бухгалтерский" отчёт?.. Поясню примером... Вот конструктор начертил стол. У стола четыре ножки. Очевидно столько ножек и попадёт в данный отчёт. Но технолог скажет, что это не так, на стол расходуется 4,12 ножки... и он будет прав, потому что на каждые 100 столов будет израсходовано 412 ножек (12 штук - это бракованные ножки, которые должны быть списаны, но они тоже входят в затраты на приобретение/изготовление). Но и это ещё не всё. Ножки покупались по цене 3 р. 23 коп., но в производство они идут по цене 4 р. 56 коп. Поскольку вторая цена (она называется ценой заготовления или "внутренней" ценой) включает в себя затраты на транспортировку, погрузочно-разгрузочные работы, стоимость хранения и пр. Но в накладной от поставщика, есть только первая цена (3 р. 23 коп.). Работаем себе в убыток?.. Или всю эту информацию (и множество другой) сваливаем в бухгалтерию, а потом включаем в отчёт?.. И кому будет нужен отчёт длинной... в несколько километров?.. Проще заново сосчитать/прикинуть какой-то показатель, чем найти его в этом отчёте.

[alexus]

Дело не в задаче, а в структуре БД... (это совсем разные вещи).

А что со структурой не так?

Эта структура отражает представление бухгалтера о производстве. Но представления бухгалтера о производстве и реальное производство - "две большие разницы"... (при этом информационная модель любого производства существенно проще и полнее, чем представления бухгалтера).
Афоризм Козьмы Пруткова № 66: " Многие вещи нам непонятны не потому, что наши понятия слабы; но потому, что сии вещи не входят в круг наших понятий".

[alexus]

Анализирует.... Иначе этот отчет и не нужен был бы.
Там вообще ничего фиксированного нет.
Все данные в одной таблице

Так об этом же и спрашивали... сведены уже (до начала формирования отчёта) данные в одну таблицу или нет... Я Вас понял так, что данные не сведены... поэтому и говорил об иерархии показателей/запросов. Если данные уже сведены, значит и структура показателей уже определена (иначе было бы непонятно, какие данные в таблице). Но если данные уже сведены в таблицу, то... что мешает вывести их в виде отчёта?..

[alexus]

Эта таблица формируется отчетом или существует и поддерживается в актуальном состоянии средствами системы(1С)

Если вы про исходную таблицу, то она накапливает данные в течение месяца. Плюс в конце месяца выполняется расчет себестоимости который формирует в ней кучу записей распределения затрат.

"Распределение затрат" делается до формирования отчёта?

[alexus]

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

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

[alexus]

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

Конечно не входит. Вам таблица уже дана.
Но она в плоском виде на сервере СУБД.
Если в этой таблице выделить самую суть то будет три колонки
[на что затрачено][что затрачено][сумма]

А вам это нужно на клиенте в виде дерева вывести. Чтобы это сделать нужно эту таблицу рекурсивно обойти.
А чтобы ее рекурсивно обойти вам нужно закачать ее на клиента. А на клиенте она в оперативу вся не влезет.
Это трабл.
Но нам нужна ведь не вся таблица. А только то что входит в наше дерево. Мы например сделали отбор по одному виду продукции. Т.е. из 10м строк в разузловании будут учавствовать только 500 например.
Но вы не можете получить одним запросом эти 500 строк, т.к. вам не известна глубина дерева!!!
Это трабл.
Можно запросом получать затраты по каждому полученному элементу дерева. Но запросы тяжелые, и отчет будет формироваться очень долго.
Это трабл.

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

[alexus]

Предыдущее сообщение было отправлено неоконченным, простите.

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

Конечно не входит. Вам таблица уже дана.
Но она в плоском виде на сервере СУБД.
Если в этой таблице выделить самую суть то будет три колонки
[на что затрачено][что затрачено][сумма]

А вам это нужно на клиенте в виде дерева вывести. Чтобы это сделать нужно эту таблицу рекурсивно обойти.
А чтобы ее рекурсивно обойти вам нужно закачать ее на клиента. А на клиенте она в оперативу вся не влезет.
Это трабл.
Но нам нужна ведь не вся таблица. А только то что входит в наше дерево. Мы например сделали отбор по одному виду продукции. Т.е. из 10м строк в разузловании будут учавствовать только 500 например.
Но вы не можете получить одним запросом эти 500 строк, т.к. вам не известна глубина дерева!!!
Это трабл.
Можно запросом получать затраты по каждому полученному элементу дерева. Но запросы тяжелые, и отчет будет формироваться очень долго.
Это трабл.

Ничего непонятно...
Предположим, что таблица имеет примерно такую структуру:
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;Когда пользователь "щёлкает" на каком-то показателе, подставляем его идентификатор в запрос, получаем данные и выводим на экран. Происходит это очень быстро (как правило, миллисекунды для тысяч записей), поскольку по внешнему ключу [по умолчанию] создаётся индекс.

[alexus]

я про то, что данные в ЭТУ таблицу могут заносится некорректно , например, не полностью в следствии некорректного учета первичных документов (из которых рассчитываются затраты)

Так вот отчет для того и нужен в частности. Чтобы выявлять ошибки.

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