skrimafonolog

заказчик думает, что превью на протопае - уже рабочая страница и я пытаюсь развести его на деньги.
ВЕДЬ ТАМ ВСЁ КЛИКАЕТСЯ

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

Еще вариант:

Макет это картинка. Для интеграции в тему или CMS необходима вёрстка, т.е. код. Если он этого не понимает или вам не доверяет, отказывайтесь.

Никогда не верьте продавцам-консультантам.
Они в первую очередь продавцы, а на вас им плевать.

Создавать пул на 1к процессов и удивляться, что память льётся? Ну вы, батенька, извращенец

Все эти твикеры - полное убожество, не ставьте, поломаете кучу настроек.
CCleaner хорош, ещё пользуйтесь встроенной Очисткой диска.
Дефрагментатор довели до ума, так что левых качать не надо, хватит Оптимизации дисков.

Главное, не ставьте себе "бустспидов" и разного рода "улучшайзеров", прибейте пару ненужных служб и всё.

Есть такая штука - авторизация, и есть такое понятие как овнершип (владение) и ACL/RBAC. Во всех скриптах проверяется кто владелец файла, или кто может его изменять/удалять. Если у пользователя есть права на изменение/удаление объекта - скрипт отрабатывает, если нет - выдает ексепшн или иначе оповещает о неудачном завершении.

Неверно в корне.
Вы нарисовали по сути EAV (есть такая готовая схема данных под эту задачу - погуглите, примеров много).

Плюсы:
Удобно ложиться в реляционную модель, удобно программируется (если вам удобно работать с реляционной моделью), на первый взгляд хорошо подходит под любую реляционную СУБД (MySQL, PostgreSQL, Oracle).

Минусы:
Неоправдано малоэффективно по производительности.
Есть решения на порядок более быстрые.

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

По мне так EAV удобен как средство редактирования (ну и хранения первичной информации).

А вот собственно сам поиск гораздо эффективнее осуществляется на full-text search engines, например:
SphinxSearch (или его клон Мантикора), ElasticSearch и т.п.

И чем по большему количеству фильтров идет поиск - тем больше этот разрыв (хотя он и по одному фильтру уже весьма заметен).

В наиболее развитых full-text search engine поиск по свойствам является "дешевой" операцией, совершенно совместимой с основным полнотекстовый поиском.

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

Бонусом практически "бесплатно" получаете т.н. "фасеточные итоги", отвечающие на вопрос "сколько у нас товаров с таким то свойством" (это часто используется в отображении фильтров на сайтах).

====================

Вывод:

Если вам принципиально на MySQL - просто см. описание схемы данных EAV. Она как раз именно что для этого.
Если вам нужно чтобы все летало - см. SphinxSearch (он крайне быстр и нетребователен к ресурсам).

P.S.:
SphinxSearch
Умеет выдирать данные из MySQL. На их основании строит уже свой собственный узкоспециализированный но очень быстрый поиск для выборок, в вашем случае, по названию и по свойствам товаров.