Сообщение от DjDiablo
|
|
4)Прокешировать результат суммы строк. То есть, когда сервер возвращает данные он возвращает их из кеша, но если в бд произошли изменения то он считает сумму строк, записывает их в кеш и только потом возвращает результат. Определять необходимость перерасчёта суммы, можно по двум временным меткам. Одна метка, это время последней операции записи, вторая эта время (последней операции записи) которая участвовала в расчёте кеша. Если при операции получения выясняется что время последней операции не совпадает со (временем операции записи) участвующей в последнем расчёте кеша, значит кеш нужнается в перерасчёте.
|
Сколько предполагаете держать суммарных ячеек в кэши? 2-3, или 200-300? Вы предлагаете сравнивать метки времени операции. Но кроме сравнения времен необходимо еще сравнивать какие строки таблицы базы данных участвовали в операции суммирования. Как я уже сказал, применяются фильтры. В одном случае из всей таблицы выбираются только холодильники, во втором только телевизоры. Значит надо сравнивать еще и диапазон значений, который участвовал в операции, так ведь? А как? По ID записей - нельзя. Значит, в худшем случае при любом чихе в БД (update поля "количество товара") придется пересчитывать ВСЕ кеши (200-300). И в чем же мы выиграли?
|
Сообщение от DjDiablo
|
5)Перманентный расчёт суммы строк ...
Тоесть я просто отнял старую стоимость всех памперсов а потом прибавил новую. Это гораздо быстрее чем из за пары памперсов суммировать все строки в базе (десятки тысяч).
|
Скажу честно на практике этот подход не проверял, но продумывал. И решил не использовать вот по какой причине. Когда Вы изменяете количество памперсов в какой-то одной строке, то всё хорошо. Но бывают групповые операции, типа пользователь выделяет и удаляет 100 строк сразу. К чему это приведет? К тому, что вместо одного SQL-запроса по таблице надо будет сделать 100 операций.
|
Сообщение от DjDiablo
|
|
Если подытожить, то максимальное быстродействие обеспечат именно регистры, такие же как в системе 1С. Причём при помощи регистров можно реализовать 99% всех типов операций
|
Мне кажется Вы говорите об однопользователской 1С-ке. У меня запросы клиентов к базе множественные и асинхронные. И через инет. Возможно такое, что первый запрос будет подан раньше второго, а обработан позже второго! И... сплошная каша. И я её боюсь
