Привет. Есть задача, составить структуру БД так, чтобы поиск можно было осувществить алгоритмами поиска вглубь\вширину\итеративным глубинным поиском. У кого какие идеи? СУБД: MSSQL 2005
09.10.07 16:30: Перенесено модератором из '.NET' — TK
Здравствуйте, widjmak, Вы писали:
W>Привет. Есть задача, составить структуру БД так, чтобы поиск можно было осувществить алгоритмами поиска вглубь\вширину\итеративным глубинным поиском. У кого какие идеи? СУБД: MSSQL 2005
Гуглить по "деревья в SQL"
<< Ни один дурак не жалуется на то, что он таковым является. Значит, не так уж у них все плохо. >>
Здравствуйте, widjmak, Вы писали:
W>Привет. Есть задача, составить структуру БД так, чтобы поиск можно было осувществить алгоритмами поиска вглубь\вширину\итеративным глубинным поиском. У кого какие идеи? СУБД: MSSQL 2005
Здравствуйте, MasterZiv, Вы писали:
MZ>Что вы конкретно понимаете под MZ>"поиск можно было осувществить алгоритмами поиска MZ>вглубь\вширину\итеративным глубинным поиском" ?
То и имеется в виду вестимо — вглубь по дереву, в пределах одного уровня, последовательный обход дерева в глубину.
<< Не присоединяйся к нашему миру наркоманов: нас много, а наркоты мало. >>
Flamer пишет:
> То и имеется в виду вестимо — вглубь по дереву, в пределах одного > уровня, последовательный обход дерева в глубину.
OK, а зачем вам тогда для этого какая-то особая структура БД ?
Просто берите данные нужные, и обходите в нужном порядке.
Обычного представления в виде таблицы со ссылкой самой на себя хватит.
[]
MZ>OK, а зачем вам тогда для этого какая-то особая структура БД ? MZ>Просто берите данные нужные, и обходите в нужном порядке. MZ>Обычного представления в виде таблицы со ссылкой самой на себя хватит.
Во-первых, нужно это не мне. Во-вторых, в указанном вами примере невозможно одним запросом к базе вытащить всех детей нужного узла, всех родителей нужного узла, все узлы одного уровня с указанным узлом и еще много интересных вкусностей. Вместо этого придется извращаться с рекурсивными запросами.
Почитайте таки "Деревья в SQL" на досуге — интересная вещь. Я именно на них уже очень давно делаю иерархические структуры (например, каталоги товаров). Такая структура в случае необходимости произведения вложенного поиска (т.е. "искать товары в этой категории и дочерних категориях") позволяет сохранять прозрачность SQL, т.к. никаких особо извратных запросов не требует, зато очень легко позволяет обходить дерево по нужным критериям _одним_ запросом. Да, вставка и удаление сложнее и требуют перестройки дерева. Зато select всего дерева одним запросом . А структура связки ID->ParentID (о которой вы видимо и говорите) — для указанных топикстартером задач убогая сильно, и ей место разве что в структуре таблиц форумов и пр. вещей со связкой топик->родительский топик.
Честно сказать, у деревьев в SQL есть два существенных недостатка: 1) SQL не совсем прозрачен для понимания (ну да это лечится прочтением книги про структуры данных) и, 2) на очень больших таблицах построение дерева занимает ощутимое время (впрочем, эта информация могла устареть, т.к. последний раз я применял SQL-деревья в большой таблице лет 6-7 назад). Так что применять их надо с умом. И индексы настраивать.
Такой вот гон
<< Если ты не являешься частью решения, то ты являешься частью проблемы. >>
Flamer wrote: > Почитайте таки "Деревья в SQL" на досуге — интересная вещь.
Вы бы ссылку давали, чтоли.
> Честно сказать, у деревьев в SQL есть два существенных недостатка: 1) > SQL не совсем прозрачен для понимания (ну да это лечится прочтением > книги про структуры данных) и,
Ну, боюсь что это неправда Ваша.
> 2) на очень больших таблицах построение > дерева занимает ощутимое время (впрочем, эта информация могла устареть, > т.к. последний раз я применял SQL-деревья в большой таблице лет 6-7 > назад). Так что применять их надо с умом. И индексы настраивать.
Это тоже неправда.
Вообще говоря, есть два, на мой взгляд, нормальных способа построения
деревьев -- "транзитивное замыкание" и "метод вложенных множеств" (в
кавычки взяты поисковые слова в гугле). Первый более технологичен,
второй в реализации намного сложнее (нормального описания в инете просто
нет), но позволяет эффективно работать с деревьями с большими уровнями
вложенности.
Posted via RSDN NNTP Server 2.1 beta
Всё, что нас не убивает, ещё горько об этом пожалеет.
Flamer пишет:
> Во-первых, нужно это не мне. Во-вторых, в указанном вами примере > невозможно одним запросом к базе вытащить всех детей нужного узла,
Возможно.
всех > родителей нужного узла,
Ну добавь еще табличку-результат работы транзитивного замыкания.
все узлы одного уровня с указанным узлом и еще > много интересных вкусностей.
Ну, можно еще табличку добавить.
Вместо этого придется извращаться с > рекурсивными запросами.
Не, с этим лучше не надо.
> Почитайте таки "Деревья в SQL" на досуге — интересная вещь. Я именно на
Это мне читать ? Мне-то зачем ?
> книги про структуры данных) и, 2) на очень больших таблицах построение > дерева занимает ощутимое время (впрочем, эта информация могла устареть, > т.к. последний раз я применял SQL-деревья в большой таблице лет 6-7
Думаете что за 7 лет в РСУБД что-то существенно изменилось ?
. А структура связки ID->ParentID (о которой вы видимо и говорите) — для указанных топикстартером задач убогая сильно, и ей место разве что в структуре таблиц форумов и пр. вещей со связкой топик->родительский топик.
