Ответ

Misha v.3 05.12.2007 15:53

Менять структуру БД необязательно, может только лишь все-равно вылетят поля thread_id и nesting.

лично мне все равно не нравятся группировки по имени.
дело в том, что 'cpu' у родителя и 'cpu' у конкретного продукта могут быть совершенно разными сущностями.

я бы делал привязку всех параметров к продукту, но при этом значение параметра можно было-бы привязывать к любому дочернему продукту.

однако текущие вариант несколько проще.

С помощью ID продукта будет доставаться сами его данные и данные его предков (здесь в один запрос не обойтись).

да.
тут лучше сделать несколько запросов (или ввести избыточное поле что-то типа full_path/parents и т.д. чтобы одним запросом доставать всех предков).

в случае parents есть вариант в этом поле у продукта хранить всех его предков через символ-разделитель, например: у продукта с id = 22 тут будет: 1.2.3.22 или 1/2/3/22. достали объект, знаем id всех родителей, можем достать их разом. но как и с любым полем с избыточностью надо будет тратить силы на поддержание целостности этой информации.

thread_id и nesting тут не помогут, т.к. скорее всего ветки будут большие, и если надо будет доставать 4 уровень, то реально обрабатываться будет много продуктов, и толку от индекса по thread_id + nesting будет мало.

Если имеется список продуктов, то достать к ним параметры не составляет особого труда.

ну... я думаю вам, как проектировщику такой структуры БД виднее, я не обдумывал подробности, но это напоминает мне мои раздачу прав на объекты, а со сложностью запросов там у меня проблем нет :)

Клиент - это в данном случае Парсер?

понятия не имею, на чем вы это пишите (в заголовке треда было 'OFF:').
если на парсере -- значит парсер.

---