Хорошая практика? Хранение данных ... json?

Для разбивки на класс, снижение нагрузки итд.
Что-то на подобие фильтра в яндекс маркете. Если зайти в одну категорию, то там свои параметры.. Если зайти в другую, то уже другие.
Про наследование, честно уже не помню для чего я это сделал. Вроде как, для того же.

К каждой категории (уровню) свой контроллер.. и нету смысла брать параметры из одной категории в другой (там просто не окажется этого поля), возникнет ошибка.
Надо кстати позже контроллер переписать, а то 10 файлов в место одного, не хорошо.

А можете скинуть как вы реализовали ? У меня просто максимально нацеленно на определенную цель. Не получится найти "Машину" в разделе все для животных, грубо говоря)

Целость базы, ссылку плиз =)) Как вы избавляетесь от не заполненных полей? Бывает такое, что не чего написать.. И в какой базе хранине ? mysql -myisam или InnoDB ? Nosql?

Я вообще решил создавать для каждого уровня(1,2,3,4) свою таблицу, это сделает базу максимально целостной.
Получается что-то типа:
lv1Name
Id name meta img param1 param2 param3.. param 20

lv1Name2
Id name meta img param1 param2 param3.. param 22

lv2Name
Id name meta img param1 param2 param3.. param 12
И при заполнении той или ной статьи, при указании последнего ур. записываться будет туда.
И копия в основную таблицу.
id id-lv1 id-lv2 id-lv3 id-lv4 jsonData
где id индификатор
id-lv уровень(категория, под категория итд)
jsonData - там будет готовая инф.

Блин, чем дальше иду, тем сильнее запутываюсь. Надо записывать.
Ну вообщем как-то так. На 2 уровня работает =) Завтра продолжу, сегодня отдых!

Спасибо большое.

о какой нагрузке вы говорите? вы ее меряли?

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

пример store.c87406.tmweb.ru база обычная майскл, иннадб или маисам тут без разницы.

вот видите вы уже запутались, а когда вы начнете это делать то наткнетесь еще на кучу проблем. а самое страшное будет когда вы импортнете все товары начнете работать, а потом все грохнется средь бела дня. чтобы спасать весь этот ноускл вам придется писать скрипты которые будут все там ходить да сверять по вашим папкам. просто ответьте себе на вопрос - зачем? кто вам сказал про нагрузку? открывание файлов это тоже нагрузка между прочим.

ну и ссылка https://ru.wikipedia.org/wiki/%D6%E5%EB%EE%F1%F2%E...

Ну при 25 запросов в сек, он будет. Еще нет, движок протестировал, а поиск еще не до конца закончен, так что не чего тестировать. Запутался я не много в другом) Пф, товары не страшны, у меня их нету, только статьи, новости итд. Я первопроходец в этом деле, так что не чего не знаю, знаю как написать и не больше. Один кривой запрос может все испортить, но не будем о них) Вот поэтому я боюсь что-то не так сделать.

А как вы предлагаете хранить ?
1х уровней - 22
2х уровней - 120
3х уровней - больше 500
4х уровней - больше 1200
Для разбивки 2.6мил. статей.
Получается что каждый уровень уникальный и в каждом уровне от 2х до 20 параметров..
И все это лишь примерно :D

К примеру: это таблица категорий, подкатегори итд.
id name type num
В ней не кого не будет пустого поля. Правда она не в базе хранится, а в простому файле + она в кэше

65536: Кстати о чем я и говорил.. у вас в фильтре все параметры.. Да работает быстро =)

ладно сделаете расскажете

phpus: какие все?

Самописный движок или ?
Интересует вопрос про чпу, сильно грузит ?
у меня по типу domen.ru/cat/house/25632

65536: Лаг наверное, теперь все ок.
У вас для каждой категории своя таблица ? или все в одной ?

65536: Магазин прикольный, мне нравится.

самопал

gyazo.com/dce3de6dcdff2f01da1d7e743ac0981a категории
gyazo.com/82fcc2f84dfea1c4a025a17b4b9ea735 товары
gyazo.com/c6ddb376075b85f462ff1e48eae8c717 свойства
gyazo.com/6f08e80c2ec668b7ec7170609d96472b значения свойств
gyazo.com/e8acb28356814cd3a3e85ab50a0a5022 вот так хранятся, миллион штук
вот и весь магаз

что у вас за сведения про нагрузку?)) чпу это вообще просто разбор строки или простенький регксп

нагрузка это:
1. кривая архитектура бд или отсутствие нужных индексов или кривые запросы
2. нагромождения объектов в памяти, ооп ради оопа и прочий оверинжиниринг, когда для элементарного действия или вообще просто так создается какой-то объект и серверу приходится это лопатить
3. зацикленный несчастный говнокод
4. "смотрите как мы умеем все делать на регулярках"
5. большое количество открывания и чтения файлов
6. что-нибудь еще

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

65536: Так это кэш) там пару файлов.
К примеру не имеет смыла создавать таблицу в базе, когда ей будут пользоваться 10 человек.

phpus: Да, еще там 2 языка, вот почему не совсем подходит. А хранить цифры отдельно от имен, это не плохо)

phpus: решение о создании таблицы принимается не в зависимости от того сколько человек будет ей пользоваться, я и для себя любимого могу таблицу создать если этого требует логика вселенной

65536: посмотрим)
создам основную таблицу и к ней уже дополнительную. И хватит)