Не много запутался при создании БД. Есть три сущности: авторы,категории и статьи. Категории сделаны при помощи nested set т.е. есть родительская категория и дочерняя. А у статьи два условия. Чтобы всегда был только один автор и возможность добавить несколько категорий. Я не понимаю каких несколько категорий можно добавить. Родительских или дочерних было бы правильно. Я думал сделать такой вариант: выбираешь родительскую категорию..и появляется набор дочерних категорий. там выбираешь одну или несколько дочерних категорий. Так было бы нормально? или лучше сделать возможность добавить несколько родительских. Вопрос тут больше по части логики БД. Вы можете сказать что это мой выбор, но мне интересно ваше мнение.
Две таблицы. В одной id статьи и id категории(й). В другой id категории, её название и id родительской категории. Если категорий не так уж и много, или нужно всегда под рукой держать всё дерево, то вторую таблицу проще держать в XML
Независимо от структуры самих категорий, для связи между статьей и категорией(ями) понадобится таблица-связка. В документации она обычно именуется "пивот". Ты на этом этапе больше думай не об интерфейсе, типа "нажал выбрал появилось", а о внутренней структуре. Она рулит всем. И ещё о том, какие проверки, т.е. валидация входящий данных понадобится. Пользовательский интерфейс поначалу должен быть максимально простым. Сделай выпадающий список со всеми категориями, их наверное не так много чтобы ипаццо с дополнительными запросами про детей. Отладь базовый функционал. Улучшайзинг на старте противопоказан, просто застрянешь на месте.
Это понятно. ))) Только НЕВАЖНО в какой технике представлено дерево, если его можно забрать всё целиком. Суть моего предложения — не отвлекаться на звездатые технологии, а заставить работать всю задачу. Потом улучшать, если понадобится. ТС пока не очень представляет как работать с отношениями, зато у него уже НестедСетс. И какой от него профит? --- Добавлено --- Понимаешь, @mkramer, задача правильно организовать отношения, наверное это типа теста или курсового ))) И мне показалось что мысль автора утекает в сторону UI, AJAX и т.п. Могу ошибаться.