DpoHro
Новичок
Вибираю способ хранения дерева каталога
А точнее каталога каталогов ))
Задача такова.
В "системе" для каждой "фирмы", назовем это так, должна быть возможность создавать каталоги произвольной вложенности. Хотя произвольность тут условная (скорее размеры будут плавающие, от 1 до 3-4), вообще не думаю, что вложенность для моей задачи превысит цифру 3.
Но каталоги могут содержать приличное количество данных (например, автокаталог мировых брендов и марок) и у каждой фирмы он может быть свой. Свойств у них не будет кроме семантики (названий).
Так вот чтобы не тратить ваше время полез по форуму искать, какие же методы бывают. Сам ранее хранил все в 1 таблице:
id, parentId, name
Сейчас еще добавилось несколько полей по которе постоянно будут присутствовать в выборках.
Это какой "фирме" принадлежит каталог, и к какому типу он принадлежит (будет еще и такое )) ).
Итого:
id, parentId, typeId, firmId, name
Так вот возвращаясь к выбору:
Начал исследования с Nested Sets, все понравилось, но определять мне потребуется только непосредственных потомков, так как над каталогом будет работать Аякс и в виде дерева мне представлять пользователям каталоги не нужно.
может мне остаться при своем?
Тогда мне интересно вот что:
Если я добавлю в свою деревянную структуру пару typeId, firmId, то какие поля сделать ключами для ускорения работы ?
Или все же для моей задачи лучше выбрать другой способ хранения каталогов?
А точнее каталога каталогов ))
Задача такова.
В "системе" для каждой "фирмы", назовем это так, должна быть возможность создавать каталоги произвольной вложенности. Хотя произвольность тут условная (скорее размеры будут плавающие, от 1 до 3-4), вообще не думаю, что вложенность для моей задачи превысит цифру 3.
Но каталоги могут содержать приличное количество данных (например, автокаталог мировых брендов и марок) и у каждой фирмы он может быть свой. Свойств у них не будет кроме семантики (названий).
Так вот чтобы не тратить ваше время полез по форуму искать, какие же методы бывают. Сам ранее хранил все в 1 таблице:
id, parentId, name
Сейчас еще добавилось несколько полей по которе постоянно будут присутствовать в выборках.
Это какой "фирме" принадлежит каталог, и к какому типу он принадлежит (будет еще и такое )) ).
Итого:
id, parentId, typeId, firmId, name
Так вот возвращаясь к выбору:
Начал исследования с Nested Sets, все понравилось, но определять мне потребуется только непосредственных потомков, так как над каталогом будет работать Аякс и в виде дерева мне представлять пользователям каталоги не нужно.
может мне остаться при своем?
Тогда мне интересно вот что:
Если я добавлю в свою деревянную структуру пару typeId, firmId, то какие поля сделать ключами для ускорения работы ?
Или все же для моей задачи лучше выбрать другой способ хранения каталогов?
