Автор Тема: СУБД и деревья  (Прочитано 68632 раз)

ilovb

  • Hero Member
  • *****
  • Сообщений: 2538
  • just another nazi test
    • Просмотр профиля
    • Oberon systems
Re: СУБД и деревья
« Ответ #15 : Апрель 11, 2012, 02:51:47 pm »
Хотя можно только отобранный массив на сервер отослать и там преобразовать в объекты.
Понял вашу мысль. Согласен.

Но как нумеровать объекты мне все равно не понятно.

alexus

  • Гость
Re: СУБД и деревья
« Ответ #16 : Апрель 11, 2012, 03:12:03 pm »
...Неужели структура себестоимости продукции/затрат произвольна?.. Может быть поговорить с экономистами?...
Затраты только примерно планировать можно.
Затраты (себестоимость) можно и нужно планировать. Да, могут быть внеплановые затраты, но планирования это не отменяет, а, наоборот, позволяет увидеть проблемные места, а значит открывает простор для поиска решений (хотя простор очень мизерный, на самом деле).

Цитата: ilovb
Вот сломался станок например. Мастер чинит этот станок.
Работа мастера в данном случае затрата, которая имеет свою стоимость. Эта стоимость должна войти в себестоимость полуфабриката, обрабатываемого на этом станке.
Т.е. затраты это не спецификация. Нету предопределенного состава затрат. Их можно только анализировать, и влиять на их состав управленческими рычагами. Таким образом регулируют себестоимость продукции и соответственно маржинальный доход.
Для того отчет и нужен.  :)
Как учил прадедушка... К. Маркс производство включает в себя предмет труда, средства труда и живой труд. Предмет труда - это то из чего получается конечный продукт (если на промежуточной операции, то полуфабрикат), то есть, в понятие предмета труда входят сырье, комплектующие и пр. материалы. Средства труда - это оборудование (станки, в том числе), оснастка и инструменты. Живой труд - это труд рабочих/инженеров/программистов и пр. Все три ипостаси делятся на две категории: основные и вспомогательные (основные/вспомогательные материалы; оборудование; рабочие). Затраты на основные - списываются прямо на себестоимость продукции. Вспомогательные списываются на цеховые (иногда на заводские) расходы, позже они распределяются на всю выпущенную продукцию, например, пропорционально объёму (материалоёмкости), трудозатратам, стоимости или как-то ещё (не суть). Труд ремонтных рабочих - это вспомогательный труд. Ремонтные работы могут проводится по план-графику (система ППР - планово-предупредительных ремонтов) или по ситуации (поломки, аварии и т.п.). Они могут списываться на цеховые расходы, если ремонтники входят в состав цеха или ремонтные работы проводятся силами основных рабочих, или на заводские, если завод имеет централизованную службу ремонта. Расходы на восстановление оборудования после аварии являются внеплановыми и служат для оценки эффективности системы ППР (если таковая имеется на предприятии) или для оценки потерь, связанных с отсутствием системы ППР.
Как видите данный фактор (ремонт станка) должен, наряду с прочими, учитываться в структуре себестоимости.

Губанов Сергей Юрьевич

  • Hero Member
  • *****
  • Сообщений: 590
    • Просмотр профиля
    • Домашняя страница
Re: СУБД и деревья
« Ответ #17 : Апрель 11, 2012, 03:15:06 pm »
Хотя можно только отобранный массив на сервер отослать и там преобразовать в объекты.
Можно иначе. Когда клиент будет смотреть отчёт, то одномоментно на одной странице он увидит порядка 100 записей, вот только для них имена и закачать. Когда он перейдёт к просмотру другой страницы подкачать имена для других 100 записей, а для предыдущих забыть.

Но как нумеровать объекты мне все равно не понятно.
В БД создать и заполнить таблицы:

Словарь номенклатур (по сути массив)
  индекс: UInt64 (автоинкремент)
  номенклатура: Номенклатура (уникальный)

Словарь затрат (по сути массив)
  индекс: UInt64 (автоинкремент)
  затрата: Затрата (уникальный)

Дату в UInt64 и наоборот преобразовывать по функции.

Сумма наверное и так UInt64?

Далее таблицу (Дата | Номенклатура | Затрата | Сумма ) переделать в таблицу (датаКакЧислоUInt64 | индекс_номенклатуры | индекс_затраты | суммаКакЧислоUInt64).


ilovb

  • Hero Member
  • *****
  • Сообщений: 2538
  • just another nazi test
    • Просмотр профиля
    • Oberon systems
Re: СУБД и деревья
« Ответ #18 : Апрель 11, 2012, 03:58:54 pm »
Затраты (себестоимость) можно и нужно планировать.
Я и не отрицаю. Наш отчет в частности и в планировании нужен.
Но для решения нашей задачи это ничего не дает.
Как учил прадедушка...
О теории управленческого учета можно долго говорить.
Вывод то какой?

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

alexus

  • Гость
Re: СУБД и деревья
« Ответ #19 : Апрель 11, 2012, 04:06:25 pm »
Как видите данный фактор (ремонт станка) должен, наряду с прочими, учитываться в структуре себестоимости.
Отчет нам это и должен показать.
Показатели себестоимости образуют иерархию. Под каждый показатель - свой запрос, результаты запросов обрабатываются на клиенте или формируют [временную] таблицу на сервере.

ilovb

  • Hero Member
  • *****
  • Сообщений: 2538
  • just another nazi test
    • Просмотр профиля
    • Oberon systems
Re: СУБД и деревья
« Ответ #20 : Апрель 11, 2012, 04:08:13 pm »
Можно иначе...

В общем понятно. Правда для 1С такой метод не подойдет. (много причин) А вот если напрямую с СУБД работать, то вполне.

Правда остается вопрос: А если данных еще больше? Если там уже не 10м а 500м?

И разузлование в оперативе тоже интересно обсудить.  ;)

ilovb

  • Hero Member
  • *****
  • Сообщений: 2538
  • just another nazi test
    • Просмотр профиля
    • Oberon systems
Re: СУБД и деревья
« Ответ #21 : Апрель 11, 2012, 04:14:26 pm »
Показатели себестоимости образуют иерархию. Под каждый показатель - свой запрос, результаты запросов обрабатываются на клиенте или формируют [временную] таблицу на сервере.
Я не очень понимаю.... Что такое показатель? Как это храниться должно?
Можно подробнее?

Вот я формирую отчет по затратам на производство паровоза. Как ваш метод будет работать по шагам?

DIzer

  • Гость
Re: СУБД и деревья
« Ответ #22 : Апрель 11, 2012, 04:19:30 pm »
p.p.s Тут не очень важны конкретные циферы. Важно лишь понимать, что на клиента это все закачивать нет возможности, т.к. элементарно не хватит памяти. Т.е. выгребсти всю таблицу одним запросом и обойти ее рекурсией не прокатит... Получать запросом подчиненные записи на каждый элемент дерева очень дорого. Плюс если в таблице зацикливание, нам его нужно как-то обойти.
Выделенное жирным непонятно  -почему?. Задача частотная - классический подход создание drill-down (разворачивающихся по требованию) отчетов - количество уточнений  ( а следовательно запросов на их получение) невелико - на сетку нагрузка минимальная.. Насчет "зацикливания" вам сказал AlexUs.
   Помочь быстро получать временные  данные - помогают вспомогательные поля введенные в структуру базовых таблиц -их конкретный тип и количество определяется структурой БД и требуемой отчетностью. Заполняются эти поля  обычно во время некритичных  по времени операциях ( триггерами на уровне БД, или средствами пост - пред обработки 1С). Можно также, делать это  отдельной последовательностью действий (преподготовка) - но только если нет зависимостей (значение этих полей не используется в других отчетах).

ilovb

  • Hero Member
  • *****
  • Сообщений: 2538
  • just another nazi test
    • Просмотр профиля
    • Oberon systems
Re: СУБД и деревья
« Ответ #23 : Апрель 11, 2012, 04:28:08 pm »
(если по-хорошему, то начать следовало бы, наверное, с проектирования БД под предметную область)

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


Можно подкачивать, можно сформировать [временную] таблицу и потом читать из неё.

А как ее сформировать? Что в ней должно быть? Это и интересно  :)

2. Циклов в "дереве" быть не может, иначе это не "дерево", а циклический граф. Возможно, имелось ввиду, что на одну вложенную ветку ссылаются две других ветки-владельцы?.. Тогда это не "дерево", а сеть, орграф.

Да. Не может.
Но есть два момента:
1. Пользователь мог допустить ошибку при вводе данных, и случайно получился цикл.
2. Полуфабрикат может пойти на затраты сам на себя (и это не редкость)

Отчет должен конечно корректно эти ситуации обработать. И кроме того нужно бы и пользователю показать где циклы образуются.

При обнаружении цикла конечно дальнейшее разузлование в данной ветке дерева уже не имеет смысла.

В любом случае, Вам надо составить "дерево" (иерархию) запросов. Результаты этих запросов будут либо закачиваться на клиента, либо помещаться во временную таблицу (возможно потребуется более одной таблицы). Если используется вариант со временными таблицами, то создавать "дерево" лучше не с помощью ссылок на родительский узел, а с помощью диапазонов. При этом нежелательны произвольная глубина и циклы, поскольку решение будет более трудоёмким, хотя и возможным.

Какая СУБД используется?

Что значит дерево запросов?
Про глубину и циклы уже говорил.
СУБД - MS SQL Server


valexey

  • Administrator
  • Hero Member
  • *****
  • Сообщений: 1990
    • Просмотр профиля
Re: СУБД и деревья
« Ответ #24 : Апрель 11, 2012, 04:33:30 pm »
А я все еще хочу пример исходных данных чтобы таки пощупать оное дерево за… узлы :-)
"но сейчас, чтобы компенсировать растущую мощность компьютеров, программисты используют фреймворки"

DIzer

  • Гость
Re: СУБД и деревья
« Ответ #25 : Апрель 11, 2012, 04:37:16 pm »
1. Пользователь мог допустить ошибку при вводе данных, и случайно получился цикл.
2. Полуфабрикат может пойти на затраты сам на себя (и это не редкость)

1. В нормально настроенной системе такого быть не должно ( каждое изменение в наборе данных должно быть синхронизировано по логике с зависимыми данными - (иначе нарушение логики в штатном режиме) - то  есть операция если она прошла - должна быть  корректной.
2. Если это ДОПУСТИМО логикой - то структура не является деревом , по определению.

ilovb

  • Hero Member
  • *****
  • Сообщений: 2538
  • just another nazi test
    • Просмотр профиля
    • Oberon systems
Re: СУБД и деревья
« Ответ #26 : Апрель 11, 2012, 04:39:35 pm »
Выделенное жирным непонятно  -почему?. Задача частотная - классический подход создание drill-down (разворачивающихся по требованию) отчетов - количество уточнений  ( а следовательно запросов на их получение) невелико - на сетку нагрузка минимальная.. Насчет "зацикливания" вам сказал AlexUs.

Структура затрат может быть очень большой. Пользователь сразу должен развернутое дерево увидеть. У него палец отвалится по крысе клацать  :)
Да и запросы будут отнимать на вскидку секунд 15-20.... (это в простейшем случае)

Клацнул. Ждешь... Клацнул. Ждешь... У пользователя на 150 клике глаз начнет дергаться

ilovb

  • Hero Member
  • *****
  • Сообщений: 2538
  • just another nazi test
    • Просмотр профиля
    • Oberon systems
Re: СУБД и деревья
« Ответ #27 : Апрель 11, 2012, 04:43:22 pm »
2. Если это ДОПУСТИМО логикой - то структура не является деревом , по определению.

Да, допустимо. Но вывести нужно дерево. Циклы просто не разворачивать, и показывать на каком элементе образуется цикл. В таких ситуациях пользователь сам разберется. (ошибка это, или так и надо)

ilovb

  • Hero Member
  • *****
  • Сообщений: 2538
  • just another nazi test
    • Просмотр профиля
    • Oberon systems
Re: СУБД и деревья
« Ответ #28 : Апрель 11, 2012, 05:00:40 pm »
Вот тут очень хороший способ (Ctrl+F Маршрут обхода):
http://www.osp.ru/pcworld/2007/03/4199032/

Данные можно будет вытаскивать динамически и максимально быстро.

Но есть пара минусов:
1. Данные придется продублировать. Т.е. добавится еще одна таблица на 10 гигов
2. Эту таблицу нужно будет периодически заполнять.(раз в месяц) И это будет довольно долго выполняться.

DIzer

  • Гость
Re: СУБД и деревья
« Ответ #29 : Апрель 11, 2012, 05:06:56 pm »
Выделенное жирным непонятно  -почему?. Задача частотная - классический подход создание drill-down (разворачивающихся по требованию) отчетов - количество уточнений  ( а следовательно запросов на их получение) невелико - на сетку нагрузка минимальная.. Насчет "зацикливания" вам сказал AlexUs.

Структура затрат может быть очень большой. Пользователь сразу должен развернутое дерево увидеть. У него палец отвалится по крысе клацать  :)
Да и запросы будут отнимать на вскидку секунд 15-20.... (это в простейшем случае)

Клацнул. Ждешь... Клацнул. Ждешь... У пользователя на 150 клике глаз начнет дергаться
1. Структура может быть сложной , а количество данных большим...-  но если ситуацию анализирует  человек -то смысла анализировать рулон бумаги с 500 наименованиями , каждое из которых содержит с полсотни зависимых позиций -нет. Классическое решение вопроса срезка данных по входным параметрам -но полагаю, что вы это знаете- не очень понятно почему это (у вас) не работает.

2. Странно... Профилируйте запрос (сколько времени из этих 15- 20 секунд приходится на  создание выборки datamining) - если окажется , что 80%  то использованная методика получения данных неоптимизирована (выбран неудачный вид запроса (запросов) ,  выборка ведется не по проиндексированным полям), структура таблиц неоптимальна для данного вида запросов. Правда есть еще вид отчетности... сверочный - где требуется честно пересчитать данные и проверить зависимости и найти возможные нестыковки...(возможно вам стоит рассмотреть применения такого рода отчетов- но они не для новичков -для  их создания необходимо четкое понимание механизмов взаимодействия подсистем предприятия
- т.е их тяжело создавать а еще тяжелее поддерживать в актуальном состоянии).