в базе (MySQL) таблица следующего вида:
id - integer
parent_id - integer
alias - varchar
(дальше не существенно).
как видно, в таблице древовидная структура.
проблема заключается в следующем:
если у меня УРЛ вида site.ru/alias1/alias2/alias1/, как разобрать данный УРЛ?
причем первый alias1 и второй alias1 - это разные записи в БД. то есть условие задачи таково, что alias уникальный на одном уровне дерева (элементы, у которых parent_id равны), но может повторяться на разных уровнях дерева. нужно каким то образом найти id последнего alias в УРЛ.
сам я вижу 2 решения:
1. хранить весь УРЛ в текстовом виде прямо в БД для каждой записи. найти потом эту запись будет очень просто как раз по УРЛ.
2. делать запрос вида SELECT `id` FROM `table` WHERE `alias` = 'alias1' AND `parent_id`= (SELECT `id` FROM `table` WHERE `alias` = 'alias2' AND ...) и так далее вложенные SELECT до первого alias.
может есть какие то более эффективные варианты?
заранее спасибо!
Спустя 55 минут, 53 секунды (31.07.2011 - 11:23) Arni написал(а):
Сталкивался с точно таким же вопросом. Вы обязаны понимать что за все фичи приходится платить чем-то. Тут вопрос не в идеальном решении, а в том что вы теряете.
1. В случае хранения с айди и поиска страницы по айди вы экономите место на сервере базы данных и таблицы не будут так сильно пухнуть в размерах. Но, каждый запрос страницы это будет удар молотком по серверу. И тут стоит отметить момент, что чем больше глубина вложенности, тем этот удар молотка будет ощутимее. Хотя с другой стороны этого вопроса, каждый сеошник вам скажет что страницы прятать глубще чем уровень 3 не стоит, поисковики их будут опускать при индексировании как маловажные.
2. Хранить урл прямо в базе это удобно, и это не то место где вас будут за это критиковать. ЧПУ, таки отвоюет позиции в полной мере, я в этом уверен. И если ваша система не планируется как хранилище 1000 и 1000 и 10000 страниц, вам нечего беспокоится вообще. Храним ссылку в базе и ставим на этот столбец индекс для быстрого поиска.
Также я смотрю что у вас проблема с тем чтобы вытащить одним запросом всех потомков. Если таки урл в базе хранить не хотим и часто вставлять страницы не требуется то хранение дерева в виде Nested Sets даст вам гораздо больше преимуществ.
1. В случае хранения с айди и поиска страницы по айди вы экономите место на сервере базы данных и таблицы не будут так сильно пухнуть в размерах. Но, каждый запрос страницы это будет удар молотком по серверу. И тут стоит отметить момент, что чем больше глубина вложенности, тем этот удар молотка будет ощутимее. Хотя с другой стороны этого вопроса, каждый сеошник вам скажет что страницы прятать глубще чем уровень 3 не стоит, поисковики их будут опускать при индексировании как маловажные.
2. Хранить урл прямо в базе это удобно, и это не то место где вас будут за это критиковать. ЧПУ, таки отвоюет позиции в полной мере, я в этом уверен. И если ваша система не планируется как хранилище 1000 и 1000 и 10000 страниц, вам нечего беспокоится вообще. Храним ссылку в базе и ставим на этот столбец индекс для быстрого поиска.
Также я смотрю что у вас проблема с тем чтобы вытащить одним запросом всех потомков. Если таки урл в базе хранить не хотим и часто вставлять страницы не требуется то хранение дерева в виде Nested Sets даст вам гораздо больше преимуществ.
Спустя 4 часа, 56 минут, 9 секунд (31.07.2011 - 16:20) viento написал(а):
спасибо! в принципе, движок планируется более или менее универсальный по функционалу. именно поэтому и пытаемся сделать неограниченное количество уровней вложенности контента. но, в любом случае, новостной сайт на нем делать не будем. поэтому, думаю, все таки запихнем полностью УРЛ в базу.
спасибо насчет Nested Sets. щас буду изучать, с чем это едят
спасибо насчет Nested Sets. щас буду изучать, с чем это едят