Доброе утро
Посоветуйте пожалуйста как лучше хранить связи между объектами, при том что у каждого объекта может быть сколько угодно родительских объектов и сколько угодно дочерних объектов. Пока я только придумал создать отдельную таблицу с двумя калонками (что — нить типа p_ip и c_id ) где хранить в первом столбце id объекта, а во втором id дочернего объекта, т.е. для объекта с двумя дочерними объектами получется две строки. Все дочерние объекты вытягивать по первой колонке, а родителей всех — по второй. Мне кажется, что мое решение не совсем правильное, помогите пожалуйста разобраться
Здравствуйте, Chardex, Вы писали:
C> Мне кажется, что мое решение не совсем правильное, помогите пожалуйста разобраться
Вполне правильное решение, называется — связь многие ко многим. Как правило, навешивается ограничение уникальности на комбинацию полей (чтобы между двумя узлами не было двух связей); в принципе также можно на триггере проверять отсутствие циклов. Кроме того, в таблицу можно добавить еще поля — это будут атрибуты связи.
Можно нагородить и другие решения, но именно это — вариант "по умолчанию".
Здравствуйте, Softwarer, Вы писали:
S>Здравствуйте, Chardex, Вы писали:
C>> Мне кажется, что мое решение не совсем правильное, помогите пожалуйста разобраться
S>Вполне правильное решение, называется — связь многие ко многим. Как правило, навешивается ограничение уникальности на комбинацию полей (чтобы между двумя узлами не было двух связей); в принципе также можно на триггере проверять отсутствие циклов. Кроме того, в таблицу можно добавить еще поля — это будут атрибуты связи.
А для чего нужны эти атрибуты связи?
S>Можно нагородить и другие решения, но именно это — вариант "по умолчанию".
А каков наилучший, или даеже еще лучше, наибыстрый? // просто будет очень много объектов...
Здравствуйте, Chardex, Вы писали:
C>А для чего нужны эти атрибуты связи?
Хм. Они просто объективно могут понадобиться — для самых разных задач. К примеру, если мы рассматриваем сущность "боксеры", атрибутами связи будут дата боя и результат.
S>>Можно нагородить и другие решения, но именно это — вариант "по умолчанию". C>А каков наилучший, или даеже еще лучше, наибыстрый? // просто будет очень много объектов...
Поиск наибыстрейшего решения невозможно осуществлять в отрыве от конкретной задачи и конкретного сервера. К примеру, для задачи "быстро найти всех потомков данной записи, у кого нет собственных потомков" этой структуры скорее всего не хватит.
Здравствуйте, Softwarer, Вы писали:
S>Поиск наибыстрейшего решения невозможно осуществлять в отрыве от конкретной задачи и конкретного сервера. К примеру, для задачи "быстро найти всех потомков данной записи, у кого нет собственных потомков" этой структуры скорее всего не хватит.
Сервер MS SQL 2000 ( скорее всего вскором — Yukon ). А задача простая, найти все дочерние, или родительские объекты. Интересует максимально быстрое решение именно для этой задачи.
Заранее спасибо
Здравствуйте, Chardex, Вы писали:
C>Сервер MS SQL 2000 ( скорее всего вскором — Yukon ). А задача простая, найти все дочерние, или родительские объекты. Интересует максимально быстрое решение именно для этой задачи.
Хм. Полагаю, с этим запросом такая структура справится без проблем. Надо только посмотреть оптимальный вариант индексов — то ли индексы по каждому из этих полей, то ли два кластерных индекса для комбинации полей в том/другом порядке.. Это уже надо спрашивать у спецов по MS SQL или смотреть на реальном объеме данных.
S>Хм. Полагаю, с этим запросом такая структура справится без проблем. Надо только посмотреть оптимальный вариант индексов — то ли индексы по каждому из этих полей, то ли два кластерных индекса для комбинации полей в том/другом порядке.. Это уже надо спрашивать у спецов по MS SQL или смотреть на реальном объеме данных.
Спецы MS SQL, подскажите пожалуйста
Здравствуйте, Chardex, Вы писали:
S>>Хм. Полагаю, с этим запросом такая структура справится без проблем. Надо только посмотреть оптимальный вариант индексов — то ли индексы по каждому из этих полей, то ли два кластерных индекса для комбинации полей в том/другом порядке.. Это уже надо спрашивать у спецов по MS SQL или смотреть на реальном объеме данных. C>Спецы MS SQL, подскажите пожалуйста
RTFM BOL: SHOWPLAN
кратенько про индексы можно почитать, например, здесь
