Хранимая процедура MySQL против множественного выбора - PullRequest
2 голосов
/ 29 ноября 2008

Вот мой сценарий:

У меня есть таблица (давайте назовем их) узлов. Первичный ключ для каждого из них просто "node_id".

У меня есть таблица, поддерживающая иерархию узлов, только с двумя столбцами: parent_node_id и child_node_id.

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

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

Кто-нибудь, имеющий практический опыт работы с этим вопросом, знает, какой из них, вероятно, будет иметь наилучшую производительность? Я читал в Интернете вещи, которые рекомендуют оба способа.

Ответы [ 3 ]

5 голосов
/ 29 ноября 2008

«какой из них, вероятно, будет иметь лучшую производительность?»: Никто не может знать! Единственное, что вы можете сделать, это попробовать оба и ИЗМЕРИТЬ. Это, к сожалению, основной ответ на все вопросы, связанные с производительностью ... за исключением случаев, когда у вас явно есть O (n) разница между алгоритмами.

И, между прочим, «множественные родители» не составляют иерархию (в противном случае я бы порекомендовал прочитать некоторые книги Джо Селко), но DAG (прямой ациклический граф) гораздо сложнее приручить зверя ...

1 голос
/ 29 ноября 2008

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

Подробнее см. Больше деревьев и иерархий в SQL .

0 голосов
/ 29 ноября 2008

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...