|
|
|
Система с изменяющимися алгоритмами расчета.
|
|||
|---|---|---|---|
|
#18+
2 Папа Карло так по какому пути Вы пойдете? Ваш выбор из серии "лучше быть здоровым и богатым, чем бедным и больным" У вас есть конкретные примеры из Вашей практики? Если есть то хотелось бы услышать "без имен" как это было, если нет, то так и скажите что то что вы говорить основано на теории и практики нет. Ну дык? Мясоперерабатывающий комбинат (достаточно известный в Москве, еще со времен СССР). Комбинат купили и новое руководство вовсю занялось cost cutting, в результате чего участились перебои с качеством на фоне агрессивного продвижения конкурентов. Как следствие - падение продаж и уменьшение доли рынка. Я лично делал анализ дистрибьютерской сети этого комбината и СВОТ анализ для нее же. Еще одна компания (сфера услуг), новое руководство так же решило занятся снижением издержек. В результате вместо 3-х слойной туалетной бумаги стали закупать однослойную и вместо гелевых ручек шариковые всем, в т.ч. до зам директоров. Догадываетесь как после этого повысилась лояльность сотрудников? Третья впала в другую крайность в попытках замотивироать продающий персонал. При этом система мотивации менялась раз в квартал, а то и чаще. Лучшие уже ушли.... Достаточно? Да, дабы не быть голословным можно обозначить Ваше положение в компании чтобы понять угол зрения с которого сделанны выводы Я консультант по построению и автоматизации системы управленческого учета для собственников и высшего руководства. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.07.2003, 23:32 |
|
||
|
Система с изменяющимися алгоритмами расчета.
|
|||
|---|---|---|---|
|
#18+
Достаточно? Спасибо за ответы. Их достаточно. :) Как я уже говорил в этом треде: "загубить можно что угодно" и "во всем свой подход нужен". Люди не всегда умеют грамотно сделать "вещь" (thing). Например большинство писателей на вижуал бейсике уверены что нарисовать схему БД или написать СПшку это пару раз плюнуть, а то что сиквел бывает без курсоров они просто не знают. Вы, как консультант, говорили руководству чем грозят те методы что они выбрали для уменьшения затрат? Свои примеры я приводил с точки зрения трейд-оффов возникающих на начальном этапе проекторования, когда выбрав немного не тот дизайн увеличивается ТСО продукта. Ваши примеры валидны, но немного из другой оперы. Я разделяю Ваше мнение о том, что произошло с теми компаниями в которых Вам "довелось". Дабы быть even я senior data architect and manager в западной компании. занимаюсь анализом в области финансов. за спиной крупные (много млн юс)проекты в качестве лидера БД анализа и дизайна. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.07.2003, 23:52 |
|
||
|
Система с изменяющимися алгоритмами расчета.
|
|||
|---|---|---|---|
|
#18+
2 Папа Карло Дабы быть even я senior data architect and manager в западной компании. занимаюсь анализом в области финансов. Приятно познакомится Наверняка Вы знакомы с Balanced Storecard (BSC). Так вот затраты - это только один из немногих показателей. Их можно и нужно(!) сокращать, но только, при прогнозируемом изменении (которое устраивает) остальных показателей BSC. Я только это и пытался сказать все это время :) К сожалению, в реальной жизни, не часто встретишь такие оценки. По крайней мере в России. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.07.2003, 00:03 |
|
||
|
Система с изменяющимися алгоритмами расчета.
|
|||
|---|---|---|---|
|
#18+
Млин. Этого смеющегося колобка следует воспринимать как дружелюбную улыбку :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.07.2003, 00:04 |
|
||
|
Система с изменяющимися алгоритмами расчета.
|
|||
|---|---|---|---|
|
#18+
у меня есть проблемма. :( я не всегда могу сказать то что хочу нужными словами. просто забываю русский язык. :( иногда доходит до смешного... :() в целом мы с вами на одной ноге. :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.07.2003, 00:13 |
|
||
|
Система с изменяющимися алгоритмами расчета.
|
|||
|---|---|---|---|
|
#18+
Balanced SCorecard? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.07.2003, 00:17 |
|
||
|
Система с изменяющимися алгоритмами расчета.
|
|||
|---|---|---|---|
|
#18+
Да, конечно SCorecard, спасибо за поправку. У нас уже ночь :) просто забываю русский язык не сочтите за комплимент, но не заметно :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.07.2003, 00:37 |
|
||
|
Система с изменяющимися алгоритмами расчета.
|
|||
|---|---|---|---|
|
#18+
<offtopic state="on"> пример того как забывается язык. год назад стоял разговаривал с рисским народом о чем-то, стояли смеялись. так вот я что-то рассказывал и забыл слово "лоб" и стою, хлопаю себя по люу и спашиваю как это по-русски называется. народ выпал в осадок. смеялись над этим потом с неделю. :) слова которые не используются в активной речи постепенно вылетают.... то же самое происходит и с англ. языком..... <offtopic state="off"> ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.07.2003, 00:45 |
|
||
|
Система с изменяющимися алгоритмами расчета.
|
|||
|---|---|---|---|
|
#18+
2 Gt_ >p.s. а про гугл вы не в ту степь, во первых это не рсубд, во вторых думаю там >объем такой что о репликации речь не может идти ... Так и я про то. Гугл был приведен чуть выше как аргумент в пользу успешности многозвенной архитектуры вообще и в обсуждаемой задаче в частности. Я и сказал, что это аргумент не в тему. 2 Gt_ && xtony Вы неявно делаете предположение, что кэш в среднем слое спланирован правильно т.е.: 1) хранит то что нужно и 2) не хранит лишнего. Если это условие не соблюдено, то средний слой будет постоянно лазить в БД или же в начале расчета читать все подряд, и в результате получатся те же тормоза, от короых мы пытаемся избавиться . Плюс в случае изменения алгоритмов расчетов его (кэш) возможно нужно будет препланировать, поскольку могут потребоаться новые данные, которых, если соблюдено условие 2), там скорее всего нет. А данные в БД еще меняются иногда. Это все относится и к одному и ко многим компьютерам в среднем слое. Но такое планирование кэша представляет собой отдельную серьезную задачу, соизмеримую по сложности с решаемой проблемой. У ASCRUS -а и близко не было ресурсов для борьбы еще и со средним слоем. Так что все сделано правильно. А еще при этом нужно помнить, что SQL сервера создавались для обработки данных и с ними конкурировать непросто. Но вообще я согласен: выигрыш на многозвенной архитектуре получить в принципе (не всегда) можно, а на всяких хитрых задачах даже очень большой. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.07.2003, 02:24 |
|
||
|
Система с изменяющимися алгоритмами расчета.
|
|||
|---|---|---|---|
|
#18+
гугл был приведен не как пример распределенной системы. прошу понять меня правильно. "абстрактной" системы. этим примером прежде всего показывалось не приимущество что двузвенки круче трезвенок и не наоборот (изначальный спор). показывалось что существуют варианты и "говорить за всех" не правильно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.07.2003, 02:51 |
|
||
|
Система с изменяющимися алгоритмами расчета.
|
|||
|---|---|---|---|
|
#18+
блин..... "гугл был приведен не как пример распределенной системы" читать как "гугл был приведен как пример распределенной системы" ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.07.2003, 02:52 |
|
||
|
Система с изменяющимися алгоритмами расчета.
|
|||
|---|---|---|---|
|
#18+
2 agg >> На практике, в правильно спроектированных клиент-серверных системах, такого влияния одного расчета на всех нет. Что-то я плохо понял ответ. Или вообще не понял. 1. Если вы считаете, что нет систем, которые производят какой-то расчет за более, чем одну секунду... Тогда я могу поставить вам такую задачу: требуется сделать так, чтобы пустой цикл исполнялся одни сутки. Дебильная задача? А может заказчику именно эта задача и нужна. То есть, задачи, которые занимают продолжительное время есть. 2. Если вы считаете, что SQL-сервера умеют так распараллеливать запросы пользователей, что даже незаметно, работает ли там один пользователь или 1000, то почему же я иду пить кофе, когда мой напарник запускает расчет на тестинг? 2 c127 Имеется достаточно много задач, которые не решаются запросами. Очень сомнительно, что будет получен выигрыш во времени для реализации их на стороне сервера (для себя я год назад эксперименты уже проводил, может быть сейчас в серверах что-то поменялось - можно будет проверить), даже если кэш на среднем слое будет реализован хреновенько. Еще хотелось бы заострить внимание на самой разработке. Трассировать средний слой будет попроще, чем хранимку. Трассирование хранимок я видел только на InterBase. На Оракле не работал, не знаю, а вот на MSSQL что-то не встречал. Чтобы не быть оффтопиком. ;) 1. Разве нет систем, где вообще реализованы внутренние языки, на которых пользователь может реализовать свой любой алгоритм? Это тоже системы с изменяющимися алгоритмами, сделанные на трехзвенке. То есть, реализация изм.алгоритмов на клиент-сервере, это не панацея, а вариант реализации. 2. Где-то проскользнула фраза "в то время, когда происходит расчет на среднем слое, данные в БД могут измениться". Я предпочитаю вытаскивать все, что нужно сразу, чтобы измененные за время расчета данные не попадали в расчет (думаю, по понятным причинам). По-поводу "лишних" данных. Если сущность насчитывает мало объектов, то я предпочитаю выгребать все сразу. Например тарифов у меня будет на дату штук 100-200. Я даже заморачиваться не буду, чтобы смотреть кто из них нужен, а кто нет для расчета. А вот клиентов я вытащу только тех, кого нужно расчитывать - зачем мне толпа клиентов та нерасчитываемых? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.07.2003, 15:10 |
|
||
|
Система с изменяющимися алгоритмами расчета.
|
|||
|---|---|---|---|
|
#18+
Эх, хотел чего нибудь еще рассказать, да пока времени нет :) Но вопросик все таки народу, работающему с 3-им звеном задам - распределенность понятно, выигрыш по кол-ву коннектов понятно, лицензии тоже понятно, еще много чего понятно. Но в кач-ве примера выигрыша среднего слоя еще многие приводят аргумент о "сложных расчетах", которые невозможно провести средствами SQL сервера. Если не сложно, не могли бы уважаемые знатоки привести примеры таких вот расчетов, которые им приходилось реализовывать в проектах и которые точно не могли бы быть реализованы с помощью средств самих СУБД. Было бы очень полезно и интересно, во всяком случае мне, чтобы иметь основные представления о проектах, реализуемых с использованием среднего звена и его целесообразности применения в каждом конкретном случае. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.07.2003, 17:05 |
|
||
|
Система с изменяющимися алгоритмами расчета.
|
|||
|---|---|---|---|
|
#18+
Но в кач-ве примера выигрыша среднего слоя еще многие приводят аргумент о "сложных расчетах", которые невозможно провести средствами SQL сервера. с помощью скл сервера можно производить любые расчеты. даже если прикинуть что транзакт сиквел ущербен, то мы можем писАть расширенные СПшки, что покрывает все остальное. Но! ....хмм всегда есть но..... СКЛ Сервер хорошо работает с реляционными операциями и для всего остального он менее эффективен. Как известно расчеты не всегда реляционные. Мы можем использовать реляционную структуры для хранения (важное слово) но описывать бизнес на транзакт сиквеле не всегда правильно. Почему? Как известно основныи задачами БД является хранить информацию и обеспечивать ее целостность. Когда мы помещаем, кроме дата логики, бизнесс-логику в БД то мы должны отдавать себе отчет в том, что мы уменьшаем производительность ДБ серсера (число транзакций которые он может выполнить). При этом стоимость транзакции растет. Как известно БД это shared (какое русское слово?) ресурс. Т.е. в больших системах с большой конкуренцией и большим объемом данных перфоманс системы может просесть до нуля только из-за того что скл сервер вместо аппликейшен сервака выполняет бизнес логику. Если так-же принять что масштабировать средний слой много проще и главное дешевле чем БД.... Двузвенка с логикой в БД может дать приимущество перед распределенной системой только на маленьких проектах (зарплата например). Можно делать двузвенку с логикой на клиенте, но если безопасность системы играет роль (например интернет решение), то размещать логику на клиенте себе дороже. :) Получается возвращаемся в базу с логикой или на аппликейшен layer. Что выбрать? Для меня персонально приходят автоматически распределенная система и кешами. === Безотносительно к теме: Дураки учаться на соих ошибках Умные на ошибках дураков Мудрые ошибки предвидят. Удачи на дорогах! :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.07.2003, 20:47 |
|
||
|
Система с изменяющимися алгоритмами расчета.
|
|||
|---|---|---|---|
|
#18+
>Как известно основныи задачами БД является хранить информацию и обеспечивать ее целостность. Скорее так: хранить, обрабатывать и обеспечивать целостность. А то select получается непонятно зачем в скл введен. >Когда мы помещаем, кроме дата логики, бизнесс-логику в БД то мы должны отдавать себе отчет в том, что мы уменьшаем производительность ДБ серсера (число транзакций которые он может выполнить). Если под транзакцией понимать внутреннюю транзакцию, то число транзакций остается постоянным. Это важно. Если под транзакцией понимать обработку запроса клиента (время отклика клиенту), то да, уменьшается, а время отклика соответственно увеличивается. Но во-первых увеличивается число таких транзакций, а во-вторых в роли клиента в многозвенке выступает средний слой, который еще должен эти данные обработать, поэтому в случае одного компьютера в среднем слое совершенно неизвестно, уменьшится ли время отклика всей системы. Никто же не спорит, что на каких-то задачах трехзвенка (или толстый клиент) может дать значительный выигрыш, но давайте вернемся к конкретной обсуждаемой задаче - расчет зарплаты. ИМХО есть только два весомых аргумента в пользу среднего звена на данной задаче это удобство отладки и удобство языка программирования. Но ASCRUS говорит, что сайбейз ASA предоставляет неплохие средства для отладки, а Watcom-SQL достаточно удобный и мощный язык, так что вроде бы и тут все в порядке. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.07.2003, 23:42 |
|
||
|
Система с изменяющимися алгоритмами расчета.
|
|||
|---|---|---|---|
|
#18+
2 ASCRUS Помнишь задачку трехлетней давности по расчету пени, где следующее значение зависело от расчета предыдущего? Помнится без курсора мы ее не смогли решить. 2 папа Карло >> shared (какое русское слово?) Русское слово - "расшаренный". 2 с127 >> поэтому в случае одного компьютера в среднем слое... Экстремальничаем? Один компьютер в системе? Я, к сожалению (или к радости), с таким не встречался с тех пор, как перестал работать с парадоксовскими табличками. >> давайте вернемся к конкретной обсуждаемой задаче - расчет зарплаты Почему же тогда тема называется "Система с изменяющимися алгоритмами расчета", а не "Расчет зарплаты"? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.07.2003, 11:32 |
|
||
|
Система с изменяющимися алгоритмами расчета.
|
|||
|---|---|---|---|
|
#18+
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-ах, удаленно и т.д.) или же для порядков расчетов требуется реализация какого то сложного алгоритма. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.07.2003, 13:31 |
|
||
|
Система с изменяющимися алгоритмами расчета.
|
|||
|---|---|---|---|
|
#18+
2 ASCRUS >> Только 3 года назад не стоит забывать experience у меня в SQL был пониже, СУБД были попроще Верю, верю. :) Я бы еще с удовольствием взглянул на реализацию: 1. построения дерева по integer ParentId 2. селект всех вложенных в ноду по Id ноды 3. поиск замкнутой цепочки В дереве могут находиться замкнутые цепочки (и это нормально) и построение ветки оканчивается при достижении конца, либо если достигнут элемент, который характеризует ветку как "замкнутую". Третий пункт у меня год назад мозгов не хватило реализовать без курсоров. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.07.2003, 18:46 |
|
||
|
Система с изменяющимися алгоритмами расчета.
|
|||
|---|---|---|---|
|
#18+
ASCRUS Вопрос как специалисту - сейчас в СУБД идет тенденция расширения возможностей с помощью интеграции с ООП средствами. Например тот же Sybase ASA позволяет сейчас подключать Java и использовать расширенные хранимые процедуры, написанные на ней, внутри ХП обьявлять переменные Java классов и работать с ними, даже есть возможность хранить экземпляры обьектов в полях таблиц и работать с их свойствами и методами в запросах. По идее такие "навороты" должны позволить решать "нерешаемые" и вышеперечисленные здесь проблемы - хранение произвольного кол-ва аттрибутов, деревьев, графов, проведение сложных с точки зрения релляционной модели данных расчетов и т.д. Как Вы думаете - такие возможности реально использовать в вышеперечисленных задачах или же это тупиковое направление и единственный выход, когда на SQL не получается - все реализовывать на 3-ем звене ? как я уже говорил... за все есть своя цена. при размещении таких наворотов в БД мы (если система распределенная) нагружаем один узел. Опять-же уже говорил что масштабировать базу сложнее чем среднее звено (Вы бизнес логику называете третьим звеном? если это так, то наверное это не совсем корректно. чтобы не было конфуза давайте так: база, средний слой (бизнес логика, блл), UI (презентационный слой)). Правильно построенная система должна иметь линейную масштабируемость. Если нагрузга не распределена равномерно между узлами и у вас нет возможности "играться" ей чтобы равномерно ее распределить, то масштабируемость не будет линейной, что ведет к увеличению стоимости системы (имеется ввиду операционная стоимость). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.07.2003, 20:00 |
|
||
|
Система с изменяющимися алгоритмами расчета.
|
|||
|---|---|---|---|
|
#18+
2 xtony >3. поиск замкнутой цепочки В дереве могут находиться замкнутые цепочки (и это нормально) и построение ветки оканчивается при достижении конца, либо если достигнут элемент, который характеризует ветку как "замкнутую". Третий пункт у меня год назад мозгов не хватило реализовать без курсоров. Не бывает в дереве замкнутых цепочек по определению: дерево - граф без циклов. Но о чем идет речь понятно. Какой СКЛ сервер? ДБ2 и оракл имеют рекурсивные запросы, ими такие штуки можно делать. В классическом СКЛ врядли без курсоров можно обойтись. Наверное еще можно попытаться извернуться через UDF, но там могут быть проблемы с рекурсией (у MSSQL такие проблемы есть по-моему, насчет сайбейза не знаю). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.07.2003, 01:14 |
|
||
|
Система с изменяющимися алгоритмами расчета.
|
|||
|---|---|---|---|
|
#18+
Я тоже попытаюсь свои три копейки вставить. А почему не рассмотреть распределённые системы СУБД типа Real Application Cluster? Там ведь и механика будет более заточена под балансировку "распределённых" запросов, всяческие автоматические оптимизаторы начинают работать. То есть клиент снаружи опять работает напрямую с "сервером" БД, а за раздачу нагрузки отвечает СУБД со спецификой реляционной обработки. Вопрос №2 - почему так ополчились на курсоры? Бывают задачи, в которых курсоры работают быстрее, чем set-oriented SQL. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.07.2003, 11:02 |
|
||
|
Система с изменяющимися алгоритмами расчета.
|
|||
|---|---|---|---|
|
#18+
Не менее безотносительно к теме 2 Папа Карло Дураки учаться на соих ошибках Умные на ошибках дураков Мудрые ошибки предвидят. Неа, не так. Это больше на правду похоже: Умные люди учатся на чужих ошибках, Нормальные люди - на собственных, А дураки - ни на чем не учатся... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.07.2003, 13:14 |
|
||
|
Система с изменяющимися алгоритмами расчета.
|
|||
|---|---|---|---|
|
#18+
xtony Ну по реализациям деревьев на форумах уже не мало написано, так что при желании посмотреть как их хранить и обрабатывать можно на том же sql.ru. Также в дополнение приведу свой способ обработки деревьев, который был применен в моем проекте. Сразу оговорюсь, что такой способ хорош только для хранения деревьев с малой глубиной вложенности узлов, так как построен с использованием денормализационной структуры. Использовать буду синтаксис WatcomSQL, так как он более прост, нагляден и краток, чем TSQL. Итак для начала спроектируем таблицу, хранящую узлы дерева: Код: plaintext 1. 2. 3. Далее спроектируем таблицу, хранящую отношения узлов дерева: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 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. Получение списка всех узлов от @Node до всех дочерних: Код: plaintext 1. 2. 3. 4. 5. Получение для клиента дерева: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. Ну и так далее - при желании простор для фантазий существует. Продолжение в следующем ответе ... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.07.2003, 14:00 |
|
||
|
Система с изменяющимися алгоритмами расчета.
|
|||
|---|---|---|---|
|
#18+
Как видно при такой структуре хранения запросы для работы с иеархиями просты и сложностей не вызывают. Удивительно, но в принципе в отличие от некоторых других способов хранения деревьев для их обработки на 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. Получается, что тригер срабатывает только на вводимые извне данные о связях и автоматически "дописывает" в таблицу всех родителей для своего родителя из той же таблицы Depend, при условии, что в Depend таких записей еще нет. Дополнительно тригер проверяет совпадения условия вставки узла между узлами ветки и соотвествующим образом так преобразует ветку, чтобы дочерние узлы, имеющие родителями узлы, которые так же имеют как родителей вставляемые узлы, стали ссылаться только на вставляемые в ветку узлы. Продолжение в следующем ответе ... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.07.2003, 14:02 |
|
||
|
Система с изменяющимися алгоритмами расчета.
|
|||
|---|---|---|---|
|
#18+
При удалении связи вызывается след. триггер: Код: 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. Как видно из тригера, при удалении связей узлов, также удаляются из Depend все родители их родителей, а также связи всех родительские узлов удаляемых связей, расписанных в их "бывших" дочерних узлах. Так же тригер дополнительно проверяет совпадения условия удаления узла, имеющего дочерние узлы и преобразует ветку так, чтобы дочерние узлы стали ссылаться на родительские узлы удаляемых узлов. P.S. Уф - думаю с такой терминологией сам запутался и всех запутал :) Ей богу, легче было бы нарисовать, чем все это пытаться обьяснить :) Тригер на обновление ничего особенного не делает - просто следит за тем, чтобы никто ничего сам поменять не мог: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. Теперь скрипты изменения иеархии узлов: Код: 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. В принципе это все. Как видно такая модель хранения иеархий расширяема вверх (например организация поверх Node хранения множества деревьев), так и вниз (например хранение на Node аттрибутов, истории их изменения, поддержка изменений задним числом и т.д.). Плюс как можно заметить такая модель данных не ограничивает хранение не только множества дочерних элементов в дереве на родительский элемент, но и множества родителей для одного дочернего элемента. Итого имеем: Достоинства - легкая модель хранения, простой и быстрый доступ и обработка, малое кол-во кода Недостатки - денормализованная таблица, растущая в прогрессии в зависимости от кол-ва уровней в иеархии У меня в проекте такая модель хранения дерева используется для хранения иеархии расчетных обьектов, с ориентировочной максимальной глубиной вложенности 6, и расчетных масок, в которых посредством этой технологии так же реализовано множественное наследование (ну или можно еще сказать множество родителей) и ориентировочной максимальной глубиной вложенности 4. Эти условия хранения иеархий вполне подходят под вышеописанную модель и я со спокойной совестью реализовал в данных случаях денормализованную структуру хранения этих иеархий. P.S. Описанная модель является протестированной и рабочей. В принципе преобразовать с WatcomSQL на тот же TSQL думаю труда не составит, разве что могут возникнуть проблемы с рекурсивными вызовами тригеров, которые в ASA я элементарно разрешил через контроль существования глобальной переменной @@Depend_Oper. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.07.2003, 14:08 |
|
||
|
|

start [/forum/topic.php?fid=32&msg=32203660&tid=1545034]: |
0ms |
get settings: |
8ms |
get forum list: |
10ms |
check forum access: |
2ms |
check topic access: |
2ms |
track hit: |
150ms |
get topic data: |
9ms |
get forum data: |
2ms |
get page messages: |
58ms |
get tp. blocked users: |
1ms |
| others: | 237ms |
| total: | 479ms |

| 0 / 0 |
