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

ilovb

  • Hero Member
  • *****
  • Сообщений: 2538
  • just another nazi test
    • Просмотр профиля
    • Oberon systems
Re: СУБД и деревья
« Ответ #30 : Апрель 11, 2012, 05:37:07 pm »
1. Структура может быть сложной , а количество данных большим...-  но если ситуацию анализирует  человек -то смысла анализировать рулон бумаги с 500 наименованиями , каждое из которых содержит с полсотни зависимых позиций -нет. Классическое решение вопроса срезка данных по входным параметрам -но полагаю, что вы это знаете- не очень понятно почему это (у вас) не работает.
А что удобнее?
Сразу сформировать дерево и просто крутить его крысой или 500 раз кликнуть (с задрежкой) чтобы увидеть что там внутри?
Если бы человек не анализировал ситуацию, то отчет вообще бы смысла не имел. А о таком отчете почти каждое производственное предприятие мечтает.

Запросы реально долгие. Я же вам про реальную ситуацию говорю. Я вам могу настоящие запросы по этой таблице показать... (1к строк текста SQL обычное дело, а ведь сервак еще транслировать этот запрос должен, потом оптимальный план выбрать и т.д. и т.п.)

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

Нормально там все. Одынэсники обычно оптимальные запросы пишут, т.к. занимаются этим день и ночь  ;)

ilovb

  • Hero Member
  • *****
  • Сообщений: 2538
  • just another nazi test
    • Просмотр профиля
    • Oberon systems
Re: СУБД и деревья
« Ответ #31 : Апрель 11, 2012, 05:40:59 pm »
DIzer, и кстати можете посчитать сколько времени на одну только пересылку данных тратится в локалке 100мбит...

ilovb

  • Hero Member
  • *****
  • Сообщений: 2538
  • just another nazi test
    • Просмотр профиля
    • Oberon systems
Re: СУБД и деревья
« Ответ #32 : Апрель 11, 2012, 05:49:55 pm »
Вот поля реальной таблицы

DIzer

  • Гость
Re: СУБД и деревья
« Ответ #33 : Апрель 11, 2012, 05:51:40 pm »
1. Структура может быть сложной , а количество данных большим...-  но если ситуацию анализирует  человек -то смысла анализировать рулон бумаги с 500 наименованиями , каждое из которых содержит с полсотни зависимых позиций -нет. Классическое решение вопроса срезка данных по входным параметрам -но полагаю, что вы это знаете- не очень понятно почему это (у вас) не работает.
А что удобнее?
Сразу сформировать дерево и просто крутить его крысой или 500 раз кликнуть (с задрежкой) чтобы увидеть что там внутри?
Если бы человек не анализировал ситуацию, то отчет вообще бы смысла не имел. А о таком отчете почти каждое производственное предприятие мечтает.

Запросы реально долгие. Я же вам про реальную ситуацию говорю. Я вам могу настоящие запросы по этой таблице показать... (1к строк текста SQL обычное дело, а ведь сервак еще транслировать этот запрос должен, потом оптимальный план выбрать и т.д. и т.п.)

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

Нормально там все. Одынэсники обычно оптимальные запросы пишут, т.к. занимаются этим день и ночь  ;)
1.Вопрос не в том , что лучше - а в том что в большинстве случаев это не имеет смысла.
2. А каким образом он анализирует ? чаще всего - поиск его основывается на знании потенциально более вероятных источников проблемы и "подозрительных" цифр и зависимостей ... в явном и неявном виде - вся эта деятельность алгоритмизируется.
3. Многие мечтают -  ;) но есть люди которые их ДЕЛАЮТ (я, например, такие делал -и цена таких отчетов была соответствующая).
4. Если это так, то самое паршивое - существующая структура таблиц и данных неоптимальна для подобных выборок - лечится в лучшем случае добавлением полей в базовые таблицы, созданием дополнительных таблиц (или отображений  (views они часто бывают лучше), ну и крайняк - это сверочные отчеты по предприятию (где от Анализа ВСЕХ зависимостей не убежишь ) - комбинация вышеперечисленного возможно с созданием временных  структур и соответствующих наборов данных  вне БД.

ilovb

  • Hero Member
  • *****
  • Сообщений: 2538
  • just another nazi test
    • Просмотр профиля
    • Oberon systems
Re: СУБД и деревья
« Ответ #34 : Апрель 11, 2012, 06:05:58 pm »
2. А каким образом он анализирует ?

А кто его знает? ;D

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

Так что вам придется под его дудю плясать, если вы вообще намерены эту задачу выполнить и получить за нее деньги.  ;)
Экспертная оценка будет стоить баснословных денег. И мало какое предприятие будет за это платить (даже просто потому что руководство "не шарит")

3. Многие мечтают -  ;) но есть люди которые их ДЕЛАЮТ (я, например, такие делал -и цена таких отчетов была соответствующая).

Мы в общем то тоже сделали. ;)

ilovb

  • Hero Member
  • *****
  • Сообщений: 2538
  • just another nazi test
    • Просмотр профиля
    • Oberon systems
Re: СУБД и деревья
« Ответ #35 : Апрель 11, 2012, 06:08:39 pm »
Вот поля реальной таблицы

Да.... Погорячился я со 100 байтами  :)

DIzer

  • Гость
Re: СУБД и деревья
« Ответ #36 : Апрель 11, 2012, 06:11:29 pm »
DIzer, и кстати можете посчитать сколько времени на одну только пересылку данных тратится в локалке 100мбит...
Нафига мне это считать (время пересылки ВСЕХ данных) - НУЖНО считать время пересылки РЕАЛЬНО НЕОБХОДИМОГО набора данных - для этого у меня нет достаточно информации

DIzer

  • Гость
Re: СУБД и деревья
« Ответ #37 : Апрель 11, 2012, 06:27:50 pm »
2. А каким образом он анализирует ?

А кто его знает? ;D

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

Так что вам придется под его дудю плясать, если вы вообще намерены эту задачу выполнить и получить за нее деньги.  ;)
Экспертная оценка будет стоить баснословных денег. И мало какое предприятие будет за это платить (даже просто потому что руководство "не шарит")

3. Многие мечтают -  ;) но есть люди которые их ДЕЛАЮТ (я, например, такие делал -и цена таких отчетов была соответствующая).

Мы в общем то тоже сделали. ;)
1. А более вариантов кроме предложенных нема  (если он обычный  "прошаренный мэнагер").
2. Поэтому - разумно ему предлагать  возможные альтернативы (вместо генерации  всего набора данных) -такие люди ценятся больше чем тупые исполнители (к ним больше доверия и получают они больше заказов- как интересных, так "халявных").
3. Да приходится - если заказчик оплачивает часы (я так понимаю  что вы  сидите на "отсосе" - то есть предприятие оплачивает почасовку (закрывает часы)).
4. Поздравляю -одна  проблема все ваши построения могут рухнуть как карточный домик  - в том случае, если вы восстанавливали алгоритм обработки опираясь только на существующие структуры и зависимости.

Romiras

  • Sr. Member
  • ****
  • Сообщений: 264
    • Просмотр профиля
    • Romiras Dev Lab
Re: СУБД и деревья
« Ответ #38 : Апрель 11, 2012, 06:38:53 pm »
Я тут не советник, но, по-моему, нужно смотреть в сторону технологии OLAP, online analytical processing.

ilovb

  • Hero Member
  • *****
  • Сообщений: 2538
  • just another nazi test
    • Просмотр профиля
    • Oberon systems
Re: СУБД и деревья
« Ответ #39 : Апрель 11, 2012, 06:42:45 pm »
Поэтому - разумно ему предлагать  возможные альтернативы (вместо генерации  всего набора данных)
Мы так и поступили
... вы  сидите на "отсосе" ...
;D ;D ;D У нас это называется - проэкт  ;)
4. ... все ваши построения могут рухнуть как карточный домик ...
Мы остановились на максимально простых построениях.

ilovb

  • Hero Member
  • *****
  • Сообщений: 2538
  • just another nazi test
    • Просмотр профиля
    • Oberon systems
Re: СУБД и деревья
« Ответ #40 : Апрель 11, 2012, 06:45:01 pm »
Я тут не советник, но, по-моему, нужно смотреть в сторону технологии OLAP, online analytical processing.
Это немного другое.

DIzer

  • Гость
Re: СУБД и деревья
« Ответ #41 : Апрель 11, 2012, 06:48:43 pm »
Я тут не советник, но, по-моему, нужно смотреть в сторону технологии OLAP, online analytical processing.
А любая  современная система содержит  ее поддержку ... но она основана на формировании  предварительного набора данных  из таблиц исходной БД и  отображении срезов по ним - те формируется гипер куб данных , а визуально отображается некоторое его сечение (можно рассматривать как источник целого набора отчетов)- т.е ничего нового не дает.

ilovb

  • Hero Member
  • *****
  • Сообщений: 2538
  • just another nazi test
    • Просмотр профиля
    • Oberon systems
Re: СУБД и деревья
« Ответ #42 : Апрель 11, 2012, 07:02:31 pm »
Вот тут можно посмотреть на картинки и прикинуть масштаб реальной задачи  :)
http://www.ec-network.ru/index.php?option=com_content&task=view&id=94&Itemid=94

alexus

  • Гость
Re: СУБД и деревья
« Ответ #43 : Апрель 11, 2012, 07:56:25 pm »
Показатели себестоимости образуют иерархию. Под каждый показатель - свой запрос, результаты запросов обрабатываются на клиенте или формируют [временную] таблицу на сервере.
Я не очень понимаю.... Что такое показатель? Как это храниться должно?
Можно подробнее?
Показатель - это то, что выводите в каждой строке отчёта. Поскольку мы говорим о затратах, то каждый вид затрат - это и есть показатель. Чтобы получить данные для расчёта показателя необходимо составить запрос к БД. Сами показатели составляют иерархию. Для рассмотренного ранее примера:
Структура цеховых затрат:
.... 1. Фонд оплаты труда:
.... 1.1. Оплата управленческого персонала;
.... 1.2. Оплата ремонтной службы;
.... 1.3. Оплата уборщиц и подметальщиц;
.... 2. Приобретение оборудования
.... 2.1. Основное технологическое оборудование;
.... 2.2. Вспомогательное оборудование;
.... 2.3. Офисное оборудование и принадлежности;
.... 2.4. Оборудование для пищеблока;
.... 3. Затраты на вспомогательные материалы;
.... 3.1. Затраты на спец. одежду и средства индивидуальной защиты;
.... 3.2. Затраты на протирочные материалы;
.... 3.3. Затраты на смазочные материалы;
.... 3.4. Затраты на ремонтные материалы;
.... 3.4.1. Крепежные изделия;
.... 3.4.2. Подшипники;
.... 3. 4.3. ....
....................
 
Цитата: ilovb
Вот я формирую отчет по затратам на производство паровоза. Как ваш метод будет работать по шагам?
Под каждый из приведённых выше (и прочих) показателей формируется свой запрос. Обходим иерархию показателей, отправляем запросы к БД, формируем строки в таблице или отчёте... Иерархия показателей и есть ничто иное, как структура затрат/себестоимости. По её поводу я Вам настоятельно рекомендую поговорить с экономистами (не с бухгалтерами!). Сами запросы можно хранить в БД, в отдельной таблице, это позволит корректировать запросы при необходимости, без переделки приложений и использовать эти запросы из разных приложений...

alexus

  • Гость
Re: СУБД и деревья
« Ответ #44 : Апрель 11, 2012, 08:11:53 pm »
(если по-хорошему, то начать следовало бы, наверное, с проектирования БД под предметную область)

На структуру исходной таблицы мы мало можем влиять. Она такая какая есть, и оптимизирована для других задач. Мы можем только дополнительные таблицы делать.
... именно поэтому я и сказал про проектирование... То, что у Вас там десятки гигабайт хранятся - косвенное свидетельство того, что БД... спроектирована... не очень корректно. По мере сопровождения такой БД её структура будет пухнуть, пока разработчики не перестанут понимать, что и где хранится.

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

А как ее сформировать? Что в ней должно быть? Это и интересно  :)
Как обычно: пишем на SQL:
CREATE TABLE NEW_TABLE (...);
В ней должны быть значения показателей для каждого вида затрат. Поскольку диапазон дат для каждой записи будет один и тот же, то хранить этот диапазон в каждой записи... нет необходимости. Поэтому в таблице будет два поля: название вида затрат и сумма затрат в данном периоде времени.

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

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

Цитата: ilovb
2. Полуфабрикат может пойти на затраты сам на себя (и это не редкость)
Это как?.. Из болта сделали тот же болт?..

Цитата: ilovb
Отчет должен конечно корректно эти ситуации обработать. И кроме того нужно бы и пользователю показать где циклы образуются.
Данные в БД должны быть максимально корректные, никакой отчёт не должен править/обрабатывать некорректные данные.

Цитата: ilovb
При обнаружении цикла конечно дальнейшее разузлование в данной ветке дерева уже не имеет смысла.
Так и не надо позволять делать циклы при вставке и изменении данных.

Цитата: ilovb
Какая СУБД используется?
Что значит дерево запросов?
см. выше.

Цитата: ilovb
СУБД - MS SQL Server
Ну, так есть же в ней триггеры... Кривовато сделано, но всё же есть. И хранимые процедуры тоже есть... Кстати, MS SQL неоптимально хранит данные, это тоже одна из причин большого объёма БД.