Маэстро, попробую прокоментировать.
Во первых любой (кроме первых двух) подход при использовании фильтра по названию или к примеру по цене, будет бесполезен. Тут только рассчитывать.
для 4)
Если речь идёт о выборках по какому то критерию обьеденяющему множество товаров (к примеру по группе товара, или по поставщику, или складу, или ещё чему нибудь подобному), то здесь количество кэшей может быть равно количеству критериев. Но если это поиск по названию, то от кеширования толку ноль, и кешировать каждую запись конечно не нужно.
Правда мне сложно представить ситуацию при которой менеджеру вдруг понадобится сумма всех товаров в названии который есть слог "Бла" )).
Для 5)
Прежде всего работа с таблицей товаров и регистрами товаров, инкапсулируется в одну сущность, и об отдельных запросах в бд говорить уже не корректно. Прямое обращение к бд нарушит целостность базы данных.
class nomenklarura {
function addItem($name,$price=0){
// начало транзакции
// запись в бд товара
// пересчёт регистра
// конец транзакции
}
}
В данном случае у нас нет иного способа создать ещё один товар кроме как обратится к методу addItem класса nomenklatura. Если нужно создать 100 товаров значит нужно сто раз обратится к методу, либо передать ему массив значений и обработать его в цикле, выполнив все операции как одну транзакцию.
А вот что касается проблемы одновременного доступа, то в мускуле проблема параллелизма должна решатся на уровне транзакций ну на худой конец при помощи системной блокировки. Я пожалуй немного подумаю над этим, а потом отпишусь.
Кстатии, также было бы интересно позаимствовать механизьм счетов из 1с. Я попозже черкну как.