Подскажите как лучше организовать данные

[Focus]

Хочу сделать каталог неограниченной глубины вложенности. Каким образом лучше организовать хранение данных?
Вижу 2 варианта

1. Держать все в базе
Id, parent_id, Kat_url, kat name

Главная категория / Подкатегория 1 / Подкатегория 2
При такой вложенности имея на входе данные "Подкатегории2" чтобы получить данные Подкатегории 1 и Главной категории необходимо сделать 3 запроса к базе. Это не есть гуд

2. Держать все в базе, но периодически формировать функцию, которая работает на основе оператора case

function get_kat_info($url)
{
switch ($url)
{
  case "kategoria2":
   $main_url="glavnaya_kategoria";
   $sub_url="podkategoria1";
   $main_title="Главная категория";
   $sub_title=" Подкатегория 1";
   break;
}
}

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

 

[c0dex]

Focus
1. Неограниченная глубина вложенности никогда не нужна
2. Для простой выборки есть Nested Sets и иже с ним
3. Почти и почитать статью про деревья в базах данных

 

[Vladson]

Неограниченная глубина вложенности никогда не нужна

Ох готов был бы поспорить, да пьян...

Она нужна хотя бы для того потому что реализовать проще либо фиксированную (1-2-3) либо плавающую (1 и более) так вот никогда не знаешь сколько именно пригодится, по этому если уж в ТЗ написано делать "1 и более", то и делать "1 и более" даже если "2^999" не пригодится реально в ближайшие 200 лет, всё равно в ТЗ сказано делать "1 и более"

увеличивается к-во запросов к базе

И что ? Узкое место ? Сервак тормозит ?

Ну добавьте тупо в базе/файле/оперативке кеш-ячейку где храните готовый сериализованный массив, категории то не добавляются после каждого посещения страницы, а один раз при добавлении категории вполне можно позволить себе 3 и даже 5 запросов вместо одного... Это же каталог, а не дерево например комментариев (где каждый пост влияет на дерево, хотя и там не не каждый просмотр ведёт к комментарию, так что в 99% это вполне разумно даже там)

Опять же выборка идёт по ID т.е обычно INT по этому что 3 что 33 запроса, все будут настолько легковесные что узким местом это не будет

(про highload мы не говорим, там вопрос такой даже не стоит, хотя и о нём мог бы рассказать)

 

[grigori]

c0dex под неограниченностью подразумевается неопределенность

 

[Redjik]

Ну добавьте тупо в базе/файле/оперативке кеш-ячейку где храните готовый сериализованный массив, категории то не добавляются после каждого посещения страницы, а один раз при добавлении категории вполне можно позволить себе 3 и даже 5 запросов вместо одного... Это же каталог, а не дерево например комментариев (где каждый пост влияет на дерево, хотя и там не не каждый просмотр ведёт к комментарию, так что в 99% это вполне разумно даже там)
Опять же выборка идёт по ID т.е обычно INT по этому что 3 что 33 запроса, все будут настолько легковесные что узким местом это не будет

+1, так же делаю, не очень люблю nested sets

 

[c0dex]

Redjik
Люби не люби, да почаще взглядывай, пока что это единственное известное мне решение, которое позволяет одним запросом выбрать все дерево. Я не беру в расчет "сериализованные" массивы и кеши.

Нестед сет хорош тем, что быстр на выборках, а вот при добавлении категории там происходит вал апдейтов, что нехорошо, но вовсе не критично. Категории не каждый день добавляются в каталоги =)

 

[Redjik]

c0dex
да не, я делал nested sets, просто чаще оказывается, что вся его мощь не нужна