добрый день
есть дерево:
200 категорий
в каждой 50 подкатегорий
в каждой 25 подПОДкатегорий
итого 250000

задача:
добавить товар в несколько [под]категорий
и чтобы при редактировании товара можно было видеть, куда он добавлен, можно было удалять его из одной категории, добавлять в другую итд

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

чтобы не изобретать велосипед интересно послушать, как это принято реализовывать?

меня интересует не столько именно проектирование БД, а фронт-энд реализация

Кот Матроскинtip78меня интересует не столько именно проектирование БД, а фронт-энд реализация

Поэтому Вы написали в "Проектирование БД"? Толково.
т.к. проектирование БД тут занимает солидную часть
а вам лишь бы потроллить.

Dimitry SibiryakovОбычно люди не связываются с УЕБ-интерфейсом без необходимости. В традиционных интерфейсах
всё просто: подкатегории в дереве загружаются по мере разворачивания узлов.

а "традиционные" это кто?

Addxtip78,

Я вот тоже не понимаю, с чем у Вас проблема. Любой сервер БД будет такие объемы щелкать, как орешки.
Реализация клиента сильно зависит от того, на чем Вы его реализуете. Думаю, Вам стоит написать в раздел по соответствующей среде. Задача абсолютно типовая.
я за нагрузку не спрашивал, задача совершенно другая стоит

Dimitry SibiryakovArm79Так вроде Ajax на web-клиенте также позволяет подгружать данные по мере
необходимости?
Ajax занимает такой объём, что дешевле все 100500 записей вывалить в страницу сразу вместо
него.

что за фееричный бред?

Arm79Dimitry SibiryakovAjax занимает такой объём, что дешевле все 100500 записей вывалить в страницу сразу вместо
него.
При указанных объемах 250 т. записей - это 3-4 мегабайта. JQuery исчисляется единицами и десятками килобайт. А ведь теоретически он и не нужен, это всего лишь очень удобная обертка.
а ещё jquery != ajax ;)
и jquery тут вообще 10е дело
блин, вы всё не о том

alexeyvgtip78блин, вы всё не о томДык при чём тут "Проектирование БД"? Тут вопросами и решениями является модель базы. Вы что хотите получить, задавая вопрос, какие таблицы должны быть в модели данных? Если нет, то вопрос не сюда. Если да, то вам уже написали - должны быть одна или две таблицы с отношениями многие-ко-многим.
там вообще глухо
я может непонятно объяснил, но поверьте на слово - проектирование БД тут занимает солидную часть при разработке
с проектированием я сам в состоянии разобраться, но без представления внутренностей БД не реально правильно ответить на вопрос и реализовать задачу

там, это в разделе по frontend-разработке
тут действительно нельзя редактировать посты?