вот я напишу, а вы не поверите опять…
ваш SELECT * FROM oil будет использовать максимум один индекс, а значит если в базе 1024 товаров, из них половина в price < 30, и 1/4 в AND type in ('Castrol','Mobile'), то будет использован индекс на поле type (у вас ведь нет индекса на price+type) собственно выделив 1/4 вы дальше по базе результату пойдете простым перебором.
в случае полной нормализации ВСЕ ждойны происходят с оператором on, который задает связь по первичному ключу + если весит индекс на value то поиск по всем полям будет вестись по бинарному дереву ибо на все эти джойны будут наложен один индекс а не несколько.
а ведь есть и поля которые чисто технические (кол-во на складе) и тогда запрос: все товары, которых менее 100 на складе и размером не более 100см будут у вас бегать по разным таблицам и гемору вы отгребете не менее чем на написание конструктора SQL запроса (что я сделал за вас)
вот 5 человек заминусовало топик… Зачем спрашивается? что тут плохого именно? бывают топики какие-то хорошие — им плюс ставят, бывают плохие — им минус ставят. Ну ставишь минус — утруди себя работой объясни, а тупо пробигая "-" лепи. Такое ощушение что все индусы, которые не врубаются лепят минусы
неправильно вы думаете. Да и говорите вы неверно: Во первых если вы заранее не знаете по каким полям будет идти поиск, то вы не только проиграете по скорости с таблицей в 30 столбцов, но еще и отгребете проблему построения индексов. в вашем примере на товары, забавно будет посмотреть на то как вы будите по 1500 или 5к (это количество разных видов товаров) делать поиск по ограничивающему параметру. Вот у меня например автомобили, так там в комплектации постоянно что-то дабаляется, а что-то из списков выбора становится текстовым значением, что-то просто есть/нет (кондицианер, люк и пр.) Второй момент такой, что по скорости вы резко получаете выйгрыш после того как набрав статистику вы перенесете часть параметров в первычные. В конце концов убеждать я вас не собираюсь, я ж делюсь решением, а не навязываю его.
потому что тогда вам будет труднее добавить/удалить лишнее поле. Вот у меня задача где у объекта 40 характеристик, есть задачи, когда у объекта 400 характеристик и добавляются/удаляются
=) улыбнуло. я уж представил просто такой средне статистический высоконагруженный проект, который делают экстраспецы:
первое: Наш проЙЭкт настолько HILoad, что мы реально замарачиваемся и меняем все принты на эхи, и никаких контенинаций!!! не дай бохИ! ведь все нужно через запятую передать в эхи-это жутко принципиально!
второе: интерфейсы для лохов, их запрещено использовать по идеалогическим выскоскоростным идеалам! Вот дайте нам множественное наследование и обязательно оператор goto тогда мы покажем вам супер пупер мега оптимизацию!
третье: нам обязательно нужен Дизайнер и он будет работать с шаблонизатором, но поскольку PHP это язык шаблонов, то мы будем использовать тока PHP-Native. А да так мы еще и получим супер оптимизацию ведь мы не придумываем лишних абстракций!
Задачи кеширования мы будем решать сразу и заранее! то что нет нагрузки не проблемма- закешируем так что будет! кешируй нафиг все и сразу. Кто сказал что затраты на поддержание кеша больше чем выйгрыш? да он ламер.
короче достаточно почитать топики/коменты и станет весело
вообще индекс использован не будет ибо: `services` & n высчитываемое значение, но похоже, что если поразмыслить, то можно эту операцию разбить на индексируемые, хотя не уверен.
ваш SELECT * FROM oil будет использовать максимум один индекс, а значит если в базе 1024 товаров, из них половина в price < 30, и 1/4 в AND type in ('Castrol','Mobile'), то будет использован индекс на поле type (у вас ведь нет индекса на price+type) собственно выделив 1/4 вы дальше по базе результату пойдете простым перебором.
в случае полной нормализации ВСЕ ждойны происходят с оператором on, который задает связь по первичному ключу + если весит индекс на value то поиск по всем полям будет вестись по бинарному дереву ибо на все эти джойны будут наложен один индекс а не несколько.
а ведь есть и поля которые чисто технические (кол-во на складе) и тогда запрос: все товары, которых менее 100 на складе и размером не более 100см будут у вас бегать по разным таблицам и гемору вы отгребете не менее чем на написание конструктора SQL запроса (что я сделал за вас)
habrahabr.ru/blogs/sql/45935/
первое: Наш проЙЭкт настолько HILoad, что мы реально замарачиваемся и меняем все принты на эхи, и никаких контенинаций!!! не дай бохИ! ведь все нужно через запятую передать в эхи-это жутко принципиально!
второе: интерфейсы для лохов, их запрещено использовать по идеалогическим выскоскоростным идеалам! Вот дайте нам множественное наследование и обязательно оператор goto тогда мы покажем вам супер пупер мега оптимизацию!
третье: нам обязательно нужен Дизайнер и он будет работать с шаблонизатором, но поскольку PHP это язык шаблонов, то мы будем использовать тока PHP-Native. А да так мы еще и получим супер оптимизацию ведь мы не придумываем лишних абстракций!
Задачи кеширования мы будем решать сразу и заранее! то что нет нагрузки не проблемма- закешируем так что будет! кешируй нафиг все и сразу. Кто сказал что затраты на поддержание кеша больше чем выйгрыш? да он ламер.
короче достаточно почитать топики/коменты и станет весело
>Сам подход — использовать $block .=… — ущербный (и echo/print туда же)
это <?= стольже ущербно.
а спорить действительно неочем -) слава богам, что все больше людей это понимает
для смарти здесь:
habrahabr.ru/blogs/php/45651/#comment_1159897