powered by simpleCommunicator - 2.0.61     © 2026 Programmizd 02
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Система с изменяющимися алгоритмами расчета.
25 сообщений из 159, страница 4 из 7
Система с изменяющимися алгоритмами расчета.
    #32201407
Varivan
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
2 Папа Карло

так по какому пути Вы пойдете?

Ваш выбор из серии "лучше быть здоровым и богатым, чем бедным и больным"

У вас есть конкретные примеры из Вашей практики? Если есть то хотелось бы услышать "без имен" как это было, если нет, то так и скажите что то что вы говорить основано на теории и практики нет. Ну дык?

Мясоперерабатывающий комбинат (достаточно известный в Москве, еще со времен СССР). Комбинат купили и новое руководство вовсю занялось cost cutting, в результате чего участились перебои с качеством на фоне агрессивного продвижения конкурентов. Как следствие - падение продаж и уменьшение доли рынка. Я лично делал анализ дистрибьютерской сети этого комбината и СВОТ анализ для нее же.

Еще одна компания (сфера услуг), новое руководство так же решило занятся снижением издержек. В результате вместо 3-х слойной туалетной бумаги стали закупать однослойную и вместо гелевых ручек шариковые всем, в т.ч. до зам директоров. Догадываетесь как после этого повысилась лояльность сотрудников?

Третья впала в другую крайность в попытках замотивироать продающий персонал. При этом система мотивации менялась раз в квартал, а то и чаще. Лучшие уже ушли....

Достаточно?

Да, дабы не быть голословным можно обозначить Ваше положение в компании чтобы понять угол зрения с которого сделанны выводы

Я консультант по построению и автоматизации системы управленческого учета для собственников и высшего руководства.
...
Рейтинг: 0 / 0
Система с изменяющимися алгоритмами расчета.
    #32201412
папа Карло
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Достаточно?

Спасибо за ответы. Их достаточно. :) Как я уже говорил в этом треде: "загубить можно что угодно" и "во всем свой подход нужен". Люди не всегда умеют грамотно сделать "вещь" (thing). Например большинство писателей на вижуал бейсике уверены что нарисовать схему БД или написать СПшку это пару раз плюнуть, а то что сиквел бывает без курсоров они просто не знают. Вы, как консультант, говорили руководству чем грозят те методы что они выбрали для уменьшения затрат?

Свои примеры я приводил с точки зрения трейд-оффов возникающих на начальном этапе проекторования, когда выбрав немного не тот дизайн увеличивается ТСО продукта. Ваши примеры валидны, но немного из другой оперы. Я разделяю Ваше мнение о том, что произошло с теми компаниями в которых Вам "довелось".

Дабы быть even я senior data architect and manager в западной компании. занимаюсь анализом в области финансов. за спиной крупные (много млн юс)проекты в качестве лидера БД анализа и дизайна.
...
Рейтинг: 0 / 0
Система с изменяющимися алгоритмами расчета.
    #32201413
Varivan
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
2 Папа Карло

Дабы быть even я senior data architect and manager в западной компании. занимаюсь анализом в области финансов.

Приятно познакомится
Наверняка Вы знакомы с Balanced Storecard (BSC). Так вот затраты - это только один из немногих показателей. Их можно и нужно(!) сокращать, но только, при прогнозируемом изменении (которое устраивает) остальных показателей BSC. Я только это и пытался сказать все это время :)
К сожалению, в реальной жизни, не часто встретишь такие оценки. По крайней мере в России.
...
Рейтинг: 0 / 0
Система с изменяющимися алгоритмами расчета.
    #32201414
Varivan
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Млин. Этого смеющегося колобка следует воспринимать как дружелюбную улыбку :)
...
Рейтинг: 0 / 0
Система с изменяющимися алгоритмами расчета.
    #32201418
папа Карло
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
у меня есть проблемма. :( я не всегда могу сказать то что хочу нужными словами. просто забываю русский язык. :( иногда доходит до смешного... :() в целом мы с вами на одной ноге. :)
...
Рейтинг: 0 / 0
Система с изменяющимися алгоритмами расчета.
    #32201420
папа Карло
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Balanced SCorecard?
...
Рейтинг: 0 / 0
Система с изменяющимися алгоритмами расчета.
    #32201424
Varivan
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Да, конечно SCorecard, спасибо за поправку. У нас уже ночь :)

просто забываю русский язык

не сочтите за комплимент, но не заметно :)
...
Рейтинг: 0 / 0
Система с изменяющимися алгоритмами расчета.
    #32201425
папа Карло
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
<offtopic state="on">

пример того как забывается язык. год назад стоял разговаривал с рисским народом о чем-то, стояли смеялись. так вот я что-то рассказывал и забыл слово "лоб" и стою, хлопаю себя по люу и спашиваю как это по-русски называется. народ выпал в осадок. смеялись над этим потом с неделю. :) слова которые не используются в активной речи постепенно вылетают.... то же самое происходит и с англ. языком.....

<offtopic state="off">
...
Рейтинг: 0 / 0
Система с изменяющимися алгоритмами расчета.
    #32201437
c127
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
2 Gt_
>p.s. а про гугл вы не в ту степь, во первых это не рсубд, во вторых думаю там >объем такой что о репликации речь не может идти ...

Так и я про то. Гугл был приведен чуть выше как аргумент в пользу успешности многозвенной архитектуры вообще и в обсуждаемой задаче в частности. Я и сказал, что это аргумент не в тему.

2 Gt_ && xtony

Вы неявно делаете предположение, что кэш в среднем слое спланирован правильно т.е.: 1) хранит то что нужно и 2) не хранит лишнего. Если это условие не соблюдено, то средний слой будет постоянно лазить в БД или же в начале расчета читать все подряд, и в результате получатся те же тормоза, от короых мы пытаемся избавиться . Плюс в случае изменения алгоритмов расчетов его (кэш) возможно нужно будет препланировать, поскольку могут потребоаться новые данные, которых, если соблюдено условие 2), там скорее всего нет. А данные в БД еще меняются иногда. Это все относится и к одному и ко многим компьютерам в среднем слое.

Но такое планирование кэша представляет собой отдельную серьезную задачу, соизмеримую по сложности с решаемой проблемой. У ASCRUS -а и близко не было ресурсов для борьбы еще и со средним слоем. Так что все сделано правильно.

А еще при этом нужно помнить, что SQL сервера создавались для обработки данных и с ними конкурировать непросто.

Но вообще я согласен: выигрыш на многозвенной архитектуре получить в принципе (не всегда) можно, а на всяких хитрых задачах даже очень большой.
...
Рейтинг: 0 / 0
Система с изменяющимися алгоритмами расчета.
    #32201439
папа Карло
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
гугл был приведен не как пример распределенной системы. прошу понять меня правильно. "абстрактной" системы. этим примером прежде всего показывалось не приимущество что двузвенки круче трезвенок и не наоборот (изначальный спор). показывалось что существуют варианты и "говорить за всех" не правильно.
...
Рейтинг: 0 / 0
Система с изменяющимися алгоритмами расчета.
    #32201440
папа Карло
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
блин..... "гугл был приведен не как пример распределенной системы" читать как "гугл был приведен как пример распределенной системы"
...
Рейтинг: 0 / 0
Система с изменяющимися алгоритмами расчета.
    #32202129
xtony
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
2 agg
>> На практике, в правильно спроектированных клиент-серверных системах, такого влияния одного расчета на всех нет.

Что-то я плохо понял ответ. Или вообще не понял.
1. Если вы считаете, что нет систем, которые производят какой-то расчет за более, чем одну секунду... Тогда я могу поставить вам такую задачу: требуется сделать так, чтобы пустой цикл исполнялся одни сутки. Дебильная задача? А может заказчику именно эта задача и нужна.
То есть, задачи, которые занимают продолжительное время есть.
2. Если вы считаете, что SQL-сервера умеют так распараллеливать запросы пользователей, что даже незаметно, работает ли там один пользователь или 1000, то почему же я иду пить кофе, когда мой напарник запускает расчет на тестинг?

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

Еще хотелось бы заострить внимание на самой разработке.
Трассировать средний слой будет попроще, чем хранимку.
Трассирование хранимок я видел только на InterBase. На Оракле не работал, не знаю, а вот на MSSQL что-то не встречал.

Чтобы не быть оффтопиком. ;)
1. Разве нет систем, где вообще реализованы внутренние языки, на которых пользователь может реализовать свой любой алгоритм?
Это тоже системы с изменяющимися алгоритмами, сделанные на трехзвенке.
То есть, реализация изм.алгоритмов на клиент-сервере, это не панацея, а вариант реализации.
2. Где-то проскользнула фраза "в то время, когда происходит расчет на среднем слое, данные в БД могут измениться".
Я предпочитаю вытаскивать все, что нужно сразу, чтобы измененные за время расчета данные не попадали в расчет (думаю, по понятным причинам).
По-поводу "лишних" данных. Если сущность насчитывает мало объектов, то я предпочитаю выгребать все сразу. Например тарифов у меня будет на дату штук 100-200. Я даже заморачиваться не буду, чтобы смотреть кто из них нужен, а кто нет для расчета. А вот клиентов я вытащу только тех, кого нужно расчитывать - зачем мне толпа клиентов та нерасчитываемых?
...
Рейтинг: 0 / 0
Система с изменяющимися алгоритмами расчета.
    #32202374
Фотография ASCRUS
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Эх, хотел чего нибудь еще рассказать, да пока времени нет :)

Но вопросик все таки народу, работающему с 3-им звеном задам - распределенность понятно, выигрыш по кол-ву коннектов понятно, лицензии тоже понятно, еще много чего понятно. Но в кач-ве примера выигрыша среднего слоя еще многие приводят аргумент о "сложных расчетах", которые невозможно провести средствами SQL сервера. Если не сложно, не могли бы уважаемые знатоки привести примеры таких вот расчетов, которые им приходилось реализовывать в проектах и которые точно не могли бы быть реализованы с помощью средств самих СУБД. Было бы очень полезно и интересно, во всяком случае мне, чтобы иметь основные представления о проектах, реализуемых с использованием среднего звена и его целесообразности применения в каждом конкретном случае.
...
Рейтинг: 0 / 0
Система с изменяющимися алгоритмами расчета.
    #32202523
папа Карло
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Но в кач-ве примера выигрыша среднего слоя еще многие приводят аргумент о "сложных расчетах", которые невозможно провести средствами SQL сервера.

с помощью скл сервера можно производить любые расчеты. даже если прикинуть что транзакт сиквел ущербен, то мы можем писАть расширенные СПшки, что покрывает все остальное. Но! ....хмм всегда есть но..... СКЛ Сервер хорошо работает с реляционными операциями и для всего остального он менее эффективен. Как известно расчеты не всегда реляционные. Мы можем использовать реляционную структуры для хранения (важное слово) но описывать бизнес на транзакт сиквеле не всегда правильно. Почему?

Как известно основныи задачами БД является хранить информацию и обеспечивать ее целостность. Когда мы помещаем, кроме дата логики, бизнесс-логику в БД то мы должны отдавать себе отчет в том, что мы уменьшаем производительность ДБ серсера (число транзакций которые он может выполнить). При этом стоимость транзакции растет. Как известно БД это shared (какое русское слово?) ресурс. Т.е. в больших системах с большой конкуренцией и большим объемом данных перфоманс системы может просесть до нуля только из-за того что скл сервер вместо аппликейшен сервака выполняет бизнес логику. Если так-же принять что масштабировать средний слой много проще и главное дешевле чем БД....

Двузвенка с логикой в БД может дать приимущество перед распределенной системой только на маленьких проектах (зарплата например).

Можно делать двузвенку с логикой на клиенте, но если безопасность системы играет роль (например интернет решение), то размещать логику на клиенте себе дороже. :) Получается возвращаемся в базу с логикой или на аппликейшен layer. Что выбрать? Для меня персонально приходят автоматически распределенная система и кешами.

===
Безотносительно к теме:

Дураки учаться на соих ошибках
Умные на ошибках дураков
Мудрые ошибки предвидят.

Удачи на дорогах! :)
...
Рейтинг: 0 / 0
Система с изменяющимися алгоритмами расчета.
    #32202569
c127
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
>Как известно основныи задачами БД является хранить информацию и обеспечивать ее целостность.

Скорее так: хранить, обрабатывать и обеспечивать целостность. А то select получается непонятно зачем в скл введен.

>Когда мы помещаем, кроме дата логики, бизнесс-логику в БД то мы должны отдавать себе отчет в том, что мы уменьшаем производительность ДБ серсера (число транзакций которые он может выполнить).

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

Никто же не спорит, что на каких-то задачах трехзвенка (или толстый клиент) может дать значительный выигрыш, но давайте вернемся к конкретной обсуждаемой задаче - расчет зарплаты. ИМХО есть только два весомых аргумента в пользу среднего звена на данной задаче это удобство отладки и удобство языка программирования. Но ASCRUS говорит, что сайбейз ASA предоставляет неплохие средства для отладки, а Watcom-SQL достаточно удобный и мощный язык, так что вроде бы и тут все в порядке.
...
Рейтинг: 0 / 0
Система с изменяющимися алгоритмами расчета.
    #32202907
xtony
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
2 ASCRUS
Помнишь задачку трехлетней давности по расчету пени, где следующее значение зависело от расчета предыдущего? Помнится без курсора мы ее не смогли решить.

2 папа Карло
>> shared (какое русское слово?)
Русское слово - "расшаренный".

2 с127
>> поэтому в случае одного компьютера в среднем слое...
Экстремальничаем? Один компьютер в системе?
Я, к сожалению (или к радости), с таким не встречался с тех пор, как перестал работать с парадоксовскими табличками.

>> давайте вернемся к конкретной обсуждаемой задаче - расчет зарплаты
Почему же тогда тема называется "Система с изменяющимися алгоритмами расчета", а не "Расчет зарплаты"?
...
Рейтинг: 0 / 0
Система с изменяющимися алгоритмами расчета.
    #32203143
Фотография ASCRUS
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
xtony
Насчет пени помню :) Только 3 года назад не стоит забывать experience у меня в SQL был пониже, СУБД были попроще :) Сейчас например у меня в проекте одним запросом рассчитывается на любой месяц график посменной работы, по установленному юзером алгоритму работу (например сутки-выходной-выходной), причем у него есть дата начала действия, которая может "сбиваться" (например график вел отсчет с 1 января и по идее 1 марта должен быть выходной, но ему поставили, что теперь с 1 марта он пойдет считать смены заново). Так что и расчет пенит сейчас я думаю одним парочкой запросов можно было бы и обойтись. На самом деле у меня в проекте очень мало мест, где встречаются курсоры, причем в таких местах идет не какая то обработка данных, а обычно некоторые процессы системы расчетов (например перебор в курсоре алгоритмов по дереву иерхии обьектов и последовательный вызов через динамический SQL связанных с алгоритмами ХП).

c127
Скорее так: хранить, обрабатывать и обеспечивать целостность
Полностью согласен насчет этого высказывания. Иначе зачем тогда вообще СУБД, если их использовать только как примитивные, но надежные хранилища данных. Для такой цели и в файловой системе можно все хранить и 3-звеном все вытаскивать оттуда, обрабатывать и записывать.

папа Карло
Вопрос как специалисту - сейчас в СУБД идет тенденция расширения возможностей с помощью интеграции с ООП средствами. Например тот же Sybase ASA позволяет сейчас подключать Java и использовать расширенные хранимые процедуры, написанные на ней, внутри ХП обьявлять переменные Java классов и работать с ними, даже есть возможность хранить экземпляры обьектов в полях таблиц и работать с их свойствами и методами в запросах. По идее такие "навороты" должны позволить решать "нерешаемые" и вышеперечисленные здесь проблемы - хранение произвольного кол-ва аттрибутов, деревьев, графов, проведение сложных с точки зрения релляционной модели данных расчетов и т.д. Как Вы думаете - такие возможности реально использовать в вышеперечисленных задачах или же это тупиковое направление и единственный выход, когда на SQL не получается - все реализовывать на 3-ем звене ?

У меня например лежит почти готовый проект, который просто надо перевести на Java, макрогенератора, который позволяет обрабатывать SQL скрипты с макрокомандами и генерить на выходе "чистый" SQL. Такая штука например очень полезна для замены динамического SQL, так как на уровне макрокоманд можно довольно таки мощно управлять сборкой скриптов в пакет - фактически на выходе для СУБД получается "оптимизированный" с учетом конкретных условий и состояний данных пакетный скрипт, который просто достаточно выполнить (я бы сказал получился "аналог" ASP, только под SQL). Делать такую штуку я пока не стал по простой причине, что для расчета ЗП мне хватило обычного динамического SQL и ХП, так как расчеты начислений, налогов и удержаний вызываются последовательно в зависимости от положения их в иеархии и например никаких сложных условий порядка проведения расчетов нет. Хотя возможно все таки потом напишу, когда будет свободное время - у меня уже есть там наработки в плане подключения метаинформации и превратить макрогенератор еще и в средство генерации скриптов по абстрактным макетам и подключением метаинформации БД заманчиво, можно будет автоматизировать написание однотипных скриптов, ХП, триггеров и т.д. :) Плюс не забыть сюда добавить еще возможность расширения макрогенератора собственными plug-in классами, позволяющих вводить в макроязык новые команды и способы обработки генерации скриптов и получаем для СУБД неплохой plug-in в виде макро-языка, позволяющего в некотором роде творить чудеса и управляемый прямо из SQL :)

P.S. Кстати с таким макрогенератором скриптов встроенным в СУБД тоже думаю можно элементарно организовывать системы с изменяющимися алгоритмами расчетов, если есть необходимость хранить скрипты расчетов не в ХП, а в других местах (файлах, BLOB-ах, удаленно и т.д.) или же для порядков расчетов требуется реализация какого то сложного алгоритма.
...
Рейтинг: 0 / 0
Система с изменяющимися алгоритмами расчета.
    #32203660
xtony
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
2 ASCRUS
>> Только 3 года назад не стоит забывать experience у меня в SQL был пониже, СУБД были попроще
Верю, верю. :)
Я бы еще с удовольствием взглянул на реализацию:
1. построения дерева по integer ParentId
2. селект всех вложенных в ноду по Id ноды
3. поиск замкнутой цепочки
В дереве могут находиться замкнутые цепочки (и это нормально) и построение ветки оканчивается при достижении конца, либо если достигнут элемент, который характеризует ветку как "замкнутую".
Третий пункт у меня год назад мозгов не хватило реализовать без курсоров.
...
Рейтинг: 0 / 0
Система с изменяющимися алгоритмами расчета.
    #32203734
папа Карло
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ASCRUS

Вопрос как специалисту - сейчас в СУБД идет тенденция расширения возможностей с помощью интеграции с ООП средствами. Например тот же Sybase ASA позволяет сейчас подключать Java и использовать расширенные хранимые процедуры, написанные на ней, внутри ХП обьявлять переменные Java классов и работать с ними, даже есть возможность хранить экземпляры обьектов в полях таблиц и работать с их свойствами и методами в запросах. По идее такие "навороты" должны позволить решать "нерешаемые" и вышеперечисленные здесь проблемы - хранение произвольного кол-ва аттрибутов, деревьев, графов, проведение сложных с точки зрения релляционной модели данных расчетов и т.д. Как Вы думаете - такие возможности реально использовать в вышеперечисленных задачах или же это тупиковое направление и единственный выход, когда на SQL не получается - все реализовывать на 3-ем звене ?

как я уже говорил... за все есть своя цена. при размещении таких наворотов в БД мы (если система распределенная) нагружаем один узел. Опять-же уже говорил что масштабировать базу сложнее чем среднее звено (Вы бизнес логику называете третьим звеном? если это так, то наверное это не совсем корректно. чтобы не было конфуза давайте так: база, средний слой (бизнес логика, блл), UI (презентационный слой)). Правильно построенная система должна иметь линейную масштабируемость. Если нагрузга не распределена равномерно между узлами и у вас нет возможности "играться" ей чтобы равномерно ее распределить, то масштабируемость не будет линейной, что ведет к увеличению стоимости системы (имеется ввиду операционная стоимость).
...
Рейтинг: 0 / 0
Система с изменяющимися алгоритмами расчета.
    #32203827
c127
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
2 xtony

>3. поиск замкнутой цепочки
В дереве могут находиться замкнутые цепочки (и это нормально) и построение ветки оканчивается при достижении конца, либо если достигнут элемент, который характеризует ветку как "замкнутую".
Третий пункт у меня год назад мозгов не хватило реализовать без курсоров.

Не бывает в дереве замкнутых цепочек по определению: дерево - граф без циклов. Но о чем идет речь понятно.

Какой СКЛ сервер? ДБ2 и оракл имеют рекурсивные запросы, ими такие штуки можно делать. В классическом СКЛ врядли без курсоров можно обойтись. Наверное еще можно попытаться извернуться через UDF, но там могут быть проблемы с рекурсией (у MSSQL такие проблемы есть по-моему, насчет сайбейза не знаю).
...
Рейтинг: 0 / 0
Система с изменяющимися алгоритмами расчета.
    #32204098
KonstN
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Я тоже попытаюсь свои три копейки вставить.

А почему не рассмотреть распределённые системы СУБД типа Real Application Cluster? Там ведь и механика будет более заточена под балансировку "распределённых" запросов, всяческие автоматические оптимизаторы начинают работать. То есть клиент снаружи опять работает напрямую с "сервером" БД, а за раздачу нагрузки отвечает СУБД со спецификой реляционной обработки.
Вопрос №2 - почему так ополчились на курсоры? Бывают задачи, в которых курсоры работают быстрее, чем set-oriented SQL.
...
Рейтинг: 0 / 0
Система с изменяющимися алгоритмами расчета.
    #32204365
Фотография Циничный Кот
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Не менее безотносительно к теме

2 Папа Карло

Дураки учаться на соих ошибках
Умные на ошибках дураков
Мудрые ошибки предвидят.



Неа, не так. Это больше на правду похоже:

Умные люди учатся на чужих ошибках,
Нормальные люди - на собственных,
А дураки - ни на чем не учатся...
...
Рейтинг: 0 / 0
Система с изменяющимися алгоритмами расчета.
    #32204457
Фотография ASCRUS
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
xtony
Ну по реализациям деревьев на форумах уже не мало написано, так что при желании посмотреть как их хранить и обрабатывать можно на том же sql.ru. Также в дополнение приведу свой способ обработки деревьев, который был применен в моем проекте. Сразу оговорюсь, что такой способ хорош только для хранения деревьев с малой глубиной вложенности узлов, так как построен с использованием денормализационной структуры. Использовать буду синтаксис WatcomSQL, так как он более прост, нагляден и краток, чем TSQL. Итак для начала спроектируем таблицу, хранящую узлы дерева:
Код: plaintext
1.
2.
3.
create table Node (
  Node_Id int not null identity primary key
);

Далее спроектируем таблицу, хранящую отношения узлов дерева:
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
create table Depend (
  Node_id int not null references Node (Node_id) on delete cascade,
  Parent_id int not null references Node (Node_id) on delete cascade,
  IsExtend tinyint not null default  0 ,
  primary key (Node_id, Parent_id),
  check (IsExtend in ( 0 ,  1 ))
);

Node_id выступает ссылкой на дочерний узел, Parent_id - на родительский. Установленные для них foreign Key с каскадным удалением гарантируют целостность данных.

Теперь обьясню смысл поля-флага IsExtend:
Если рассмотреть дерево с точки зрения взаимоотношений его узлов, то фактически получается что любой узел может иметь родителя, что соотвествующе означает, что если у родителя есть другие родители, то любой узел дерева получается дочерним по отношению к всей цепочке узлов, от его родителя до корня (т.е. узла, не имеющего родителя, или замыкающего цепочку на дочерний по отношению к нему элемент). Как известно самое сложное в обработке деревьев на РСУБД - это не их хранение, а их обработка.

С учетом того, что в моем случае хранящиеся деревья имели малый уровень сложности, я решил проблему обработки деревьев путем денормализации таблицы взаимоотношений узлов Depend. Все отношения, описываемые как входящие данные, т.е. записанные в БД из вне, хранятся в флаге IsExtend с значением 0. На эти отношения в таблицу также вписывается вся цепочка от родителя до корня с значением флага 1. Денормализация на лицо - чем глубже дерево, тем больше растет таблица.

Пример:
есть отношения родитель-дочерний
узел1 -> узел2 -> узел3

в итоге в depend на узел1 не будет ни одной записи

на узел2 запись
node_id=узел2 / parent_id=узел1 / IsExtend = 0

а на узел3 уже 2 записи:
node_id=узел3 / parent_id=узел2 / IsExtend = 0
node_id=узел3 / parent_id=узел1 / IsExtend = 1

Что это дает ? Итак получение запросом глубины вложенности узла @Node от корня:
Код: plaintext
1.
2.
3.
4.
5.
select IsNull(CountNode) +  1  as Level
from (
  select count(Node_id) as CountNode
  from Depend
  where Node_id = @Node_id ) as t;

Получение списка всех узлов от @Node до всех дочерних:
Код: plaintext
1.
2.
3.
4.
5.
select Node_id
from Depend
where Parent_id = @Node_id
union all
select @Node as Node_id;

Получение для клиента дерева:
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
select Node_id, Parent_id
from Depend
where IsExtend =  0 
union all
select Node_id, null as Parent_id
from Node n
where not exists(
        select *
        from Depend
        where Node_id = n.Node_id and
              IsExtend =  0 )


Ну и так далее - при желании простор для фантазий существует.

Продолжение в следующем ответе ...
...
Рейтинг: 0 / 0
Система с изменяющимися алгоритмами расчета.
    #32204464
Фотография ASCRUS
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Как видно при такой структуре хранения запросы для работы с иеархиями просты и сложностей не вызывают. Удивительно, но в принципе в отличие от некоторых других способов хранения деревьев для их обработки на SQL в данном случае так же все просто, как и в самой обработке.
На таблицу написанны триггера на добавление и удаление записей (изменение будем считать не возможным, так как оно не имеет смысла в данной реализации). Соотвествующе при добавлении в таблицу внешним процессом связи между узлом и его родителем, с установленным флагом IsExtend в 0, вызывается след. триггер:
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.
46.
47.
48.
49.
50.
51.
52.
53.
54.
55.
56.
57.
58.
59.
60.
61.
62.
63.
64.
65.
66.
67.
68.
69.
70.
71.
72.
73.
74.
75.
76.
77.
78.
79.
80.
81.
82.
83.
84.
85.
86.
87.
88.
89.
create trigger trg_Depend_Insert
  after insert
  on Depend
  referencing new as Inserted
  for each statement
begin
  if VarExists('@@Depend_Oper') <>  0  then
    return;
  end if;

  create variable @@Depend_Oper tinyint;

   -- Добавляем связи родителей от родителей добавляемых узлов
 
  insert into Depend (Node_id, Parent_id, IsExtend)
    select t.Node_id, d.Parent_id,  1 
    from Inserted t
      inner join Depend d on d.Node_id = t.Parent_id
    where t.IsExtend =  0  and
      not exists(
        select *
        from Depend
        where Node_id = t.Node_id and 
              Parent_id = d.Parent_id);

   -- Вставляем родителями добавляемые узлы для дочерних узлов, ссылаемых на родителей
 
   -- добавляемых узлов
 
  insert into Depend (Node_id, Parent_id, IsExtend)
    select d.Node_id, t.Parent_id,  1 
    from Depend d
      inner join Depend p on p.Node_id = d.Parent_id and
                             p.IsExtend =  0 
      inner join Inserted t on t.Parent_id = p.Parent_id and
                               t.Node_id = p.Node_id and
                               t.IsExtend =  0 
    where not exists(
            select *
            from Depend
            where Node_id = d.Node_id and
                  Parent_id = t.Parent_id);

   -- Изменяем флаг родительских связей дочерних элементов на родителей
 
   -- добавляемых элементов, если есть совпадения родителей дочерних узлов и
 
   -- родителей добавляемых узлов
 
  update Depend d
  set IsExtend =  1 
  from Depend d
    inner join Inserted t on t.Node_id = d.Node_id and
                             t.IsExtend =  0 
    inner join Depend p on p.Node_id = t.Parent_id and
                           p.Parent_id = d.Parent_id and
                           p.IsExtend =  0 
  where d.IsExtend =  0 ;

  update Depend d
  set IsExtend =  1 
  from Depend d
    inner join Inserted t on t.Parent_id = d.Parent_id and
                             t.IsExtend =  0 
    inner join Depend p on p.Node_id = d.Node_id and
                           p.Parent_id = t.Node_id
  where d.IsExtend =  0 ;

   -- Вставляем родителями добавляемые узлы для всех дочерних узлов
 
  insert into Depend (Node_id, Parent_id, IsExtend)
    select d.Node_id, t.Node_id,  1 
    from Depend d
      inner join Depend p on p.Node_id = d.Parent_id
      inner join Inserted t on t.Node_id = p.Parent_id and
                               t.IsExtend =  0 
    where not exists(
            select *
            from Depend
            where Node_id = d.Node_id and
                  Parent_id = t.Node_id);

  drop variable @@Depend_Oper;

  exception
    when others then
      drop variable @@Depend_Oper;
      resignal;
end

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

Продолжение в следующем ответе ...
...
Рейтинг: 0 / 0
Система с изменяющимися алгоритмами расчета.
    #32204475
Фотография ASCRUS
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
При удалении связи вызывается след. триггер:
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.
46.
47.
48.
49.
create trigger trg_Depend_Delete
  after delete
  on Depend
  referencing old as Deleted
  for each statement
begin
  if VarExists('@@Depend_Oper') <>  0  then
    return;
  end if;

  create variable @@Depend_Oper tinyint;

   -- Устанавливаем родителей дочерних узлов на родителей удаляемых узлов
 
  update Depend d
  set IsExtend =  0 
  from Depend d
    inner join Depend p on p.Node_id = d.Node_id and
                           p.IsExtend =  0 
    inner join Deleted t on t.Node_id = p.Parent_id and
                            t.Parent_id = d.Parent_id and
                            t.IsExtend =  0 
  where d.IsExtend =  1 ;

   -- Удаляем вспомогательные связи удаляемых узлов
 
  delete Depend d
  from Depend d
    inner join Deleted t on t.Node_id = d.Node_id and
                            t.IsExtend =  0 
    inner join Depend p on p.Node_id = t.Parent_id and
                           p.Parent_id = d.Parent_id;

   -- Удаляем вспомогательные связи дочерних узлов 
 
   -- по отношению к удаляемым узлам
 
  delete Depend d
  from Depend d
    inner join Deleted t on t.Node_id = d.Parent_id and
                            t.IsExtend =  0 ;

  drop variable @@Depend_Oper;

  exception
    when others then
      drop variable @@Depend_Oper;
      resignal;
end

Как видно из тригера, при удалении связей узлов, также удаляются из Depend все родители их родителей, а также связи всех родительские узлов удаляемых связей, расписанных в их "бывших" дочерних узлах. Так же тригер дополнительно проверяет совпадения условия удаления узла, имеющего дочерние узлы и преобразует ветку так, чтобы дочерние узлы стали ссылаться на родительские узлы удаляемых узлов.

P.S. Уф - думаю с такой терминологией сам запутался и всех запутал :) Ей богу, легче было бы нарисовать, чем все это пытаться обьяснить :)

Тригер на обновление ничего особенного не делает - просто следит за тем, чтобы никто ничего сам поменять не мог:
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
create trigger trg_Depend_update 
  before update
  on Depend
  for each row
begin
  if VarExists('@@Depend_Oper') =  0  then
    raiserror  20000  'Нельзя ручками изменять иеархию';
  end if;
end


Теперь скрипты изменения иеархии узлов:
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
 -- Указываем, что узел 2 является дочерним по отношению к узлу 1
 
insert into Depend (Node_id, Parent_id)
values ( 2 ,  1 );

 -- Указываем что узел 3 является дочерним по отношению к узлу 2
 
insert into Depend (Node_id, Parent_id)
values ( 3 ,  2 );

 -- Вставляем узел 4 между узлом 2 и 3
 
insert into Depend (Node_id, Parent_id)
  select  4 ,  2 
  union all
  select  3 ,  4 ;

 -- Удаляем узел 4, что приведет к тому, что узел 2 станет снова 
 
 -- прямым родителем узла 3
 
delete from Depend
where Node_id =  4  and Parent_id =  2 ;
 --
 


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

Итого имеем:
Достоинства - легкая модель хранения, простой и быстрый доступ и обработка, малое кол-во кода
Недостатки - денормализованная таблица, растущая в прогрессии в зависимости от кол-ва уровней в иеархии

У меня в проекте такая модель хранения дерева используется для хранения иеархии расчетных обьектов, с ориентировочной максимальной глубиной вложенности 6, и расчетных масок, в которых посредством этой технологии так же реализовано множественное наследование (ну или можно еще сказать множество родителей) и ориентировочной максимальной глубиной вложенности 4. Эти условия хранения иеархий вполне подходят под вышеописанную модель и я со спокойной совестью реализовал в данных случаях денормализованную структуру хранения этих иеархий.

P.S. Описанная модель является протестированной и рабочей. В принципе преобразовать с WatcomSQL на тот же TSQL думаю труда не составит, разве что могут возникнуть проблемы с рекурсивными вызовами тригеров, которые в ASA я элементарно разрешил через контроль существования глобальной переменной @@Depend_Oper.
...
Рейтинг: 0 / 0
25 сообщений из 159, страница 4 из 7
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Система с изменяющимися алгоритмами расчета.
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]