по моему, вы не то сейчас говорите

DjDiablo, да, понял)

Наверное, я вас не понял где-то.

Маэстро, попробую прокоментировать.

Во первых любой (кроме первых двух) подход при использовании фильтра по названию или к примеру по цене, будет бесполезен. Тут только рассчитывать.

для 4)
Если речь идёт о выборках по какому то критерию обьеденяющему множество товаров (к примеру по группе товара, или по поставщику, или складу, или ещё чему нибудь подобному), то здесь количество кэшей может быть равно количеству критериев. Но если это поиск по названию, то от кеширования толку ноль, и кешировать каждую запись конечно не нужно.
Правда мне сложно представить ситуацию при которой менеджеру вдруг понадобится сумма всех товаров в названии который есть слог "Бла" )).

Для 5)
Прежде всего работа с таблицей товаров и регистрами товаров, инкапсулируется в одну сущность, и об отдельных запросах в бд говорить уже не корректно. Прямое обращение к бд нарушит целостность базы данных.

class nomenklarura {
     function addItem($name,$price=0){
           // начало транзакции
           // запись в бд товара
           // пересчёт регистра
           // конец транзакции
     }
}

В данном случае у нас нет иного способа создать ещё один товар кроме как обратится к методу addItem класса nomenklatura. Если нужно создать 100 товаров значит нужно сто раз обратится к методу, либо передать ему массив значений и обработать его в цикле, выполнив все операции как одну транзакцию.

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

Кстатии, также было бы интересно позаимствовать механизьм счетов из 1с. Я попозже черкну как.

Количество критериев может быть почти бесконечно многообразно, если в качестве критерия фильтра использовать дату/время. Например, сколько товаров (на какую сумму) поступило (или продано) с 5-го по 10-е апреля? а с 10 по 11? Также Вы говорите об ординарных фильтрах, например, выбери все товары группы "телевизоры". А как только выборка становится "мульти", так и приехали к бесконечности. Например, выбери все товары группы "телевизоры" И компании самсунг И по цене от 1000 до 2000.

Могу рассказать.
По морю ездят контейнера. В нумерации контейнеров жесткое правило: номер должен содержать 4 буквы, потом 7 цифр. Все морские компании (перевозчики) каким-то им неведомым способом кодируют свои контейнера, тем не менее, получается что-то типа:
MRKU3566361
MRKU3532370
MRKU1234567
...
Менеджер набирает в фильтре "MRKU"...
Ну, дальше Вы поняли ;)

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

P.S. Почему морские контейнеры нельзя отправить в отдельную категорию контейнеры ?

Вообще мы как-то перескочили на другую тему. Меня не сильно беспокоит время вычисления на сервере. SQL-запрос по 10000 записям считает быстро. Речь идет о том, чтобы всё же перенести вычисления на клиента, ан не получается. При условии, что информация передается порциями, то можно формулы по строке считать на клиенте, можно на сервере прямо в SQL-запросе, а можно на сервере в PHP. Суммы по колонкам придется считать только на сервере.

Можно. И так и сделано. Вся таблица - это и есть только одни контейнеры. Но... рассказываю дальше.
Думаю что Вы знаете, что практически в каждой таблице есть такое емкое поле "Примечание". В него пишут всё. Всё, что можно и не можно.
Специфика больших корпораций заключается в том, что автоматизация бизнес-процессов постоянно опаздывает за требованиями времени. Программисты могут сделать доработку через день, через месяц, через год... а менеджеру надо "на вчера"! Менеджеры не знают языка SQL, да и к базе напрямую их не пускают. Но они - народ изобретательный, поэтому используют свой "птичий" язык. Что это значит - сейчас приведу несколько примеров по памяти.

1. Потребовалось в таблице отображать признак "Документ распечатан". Ну типа статуса такого. Пока программисты думали/делали, менеджеры договорились, что в поле примечание будут писать условный сигнал {p} (наверное от слова printed). Что происходит далее? Далее производится поиск документов по полю примечание, в котором есть "{p}"

2. Знаете, что такое колка льда? Не та что для коктейлей. Когда зимой корабль заходит в порт, то ледокол дробит перед ним лед. Это выливается в доп. затраты на перевозку грузов. Когда ввели эти затраты и их надо было учитывать менеджеры тут же начали писать в примечание {лед}. Ну а дальше поиск по "{лед}".

3. Самое внезапное - это наше законодательство. Вдруг ввели некий типа налог, который называется "пошлина евро". Что сделали менеджеры? -Правильно, в примечание пишут {evro}.

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