Гаджимурадов РустамТаблоид> ну так вот: чем этот вариант "худший из возможных" ?

Основных вариантов всего 3:

1. Триггер. Пока всё так просто - лучший вариант.Ога. Особенно когда в таблице будут меняться поля НЕ из списка тех, что нужны для расчета суммы. И триггер сей всё равно будет дёргать все три(?) таблицы, чтобы обновить сумму, которая окажется той же самой :-)

Гаджимурадов Рустам2. ХП, делающая всё, что нужно, по номеру заказа.
Подробности вытаскивает сама, но они уже в кеше,
пэтому "с диском" проблем не будет. Хуже 1, лучше 3.Откуда дровишки, что "они уже в кеше", если передаётся только номер заказа ? Ты утверждаешь, что при таком раскладе никогда не будет reads > 0 ?

Гаджимурадов Рустам3. Твой вариант ХП с плохим дизайном. Худший.По дизайну - да, худший. По производительности - лучше, чем "2" (и тем более "1"), если значения наценки/доставки и прочего уже известны в вызывателе.

Гаджимурадов РустамВо-первых, это будет и в твоём варианте, так что чья бы мычала. :)
Во-вторых, никто не запрещает это проверять и не дергать.1) я НЕ предлагал вызывать ХП из триггера. И вообще пришёл как-то к "фундаментальному открытию", что row-level триггеры, дёргающиеся как свиньи на верёвке на каждый чих, по поводу и без него, есть одна из сторон Мирового Зла.. :-)
2) ХП должна вызываться только из тех мест, где действительно надо обновлять итоговую сумму заказа. Звучит как Вселенская Ересь, согласен, но главное - поменьше триггеров! Код в таком случае становится больше, появятся дублирующиеся вызовы или, еще хуже, просто повторы кусков кода, легко забыть вызвать эту ХП - всё так. Но по производительности это точно будет выигрыш.

Гаджимурадов РустамНе понял вопроса. В триггере на инсерт-апдейт записи
данные уже в кеше во всех нормальных ситуациях.Про КАКУЮ таблицу вот из этих: - ты говоришь ?
Допустим, усер выбрал в своём приложении сборку, доставку и товар (через листбокс или еще чего-то там) - да, затащил в страничный кеш ФБ эти данные из соотв. справочников.
Затем пожевал 5-10 минут, перетёр что-то с клиентом, и жмякнул "ОК". В этот момент в таблицу "заказ" добавляется строка с известными id_сборки, id_доставки, id_товара. Но откудова уверенность, что прочитанные N минут взад данные по ценам - еще сидят в кеше ? К тому же, нормальная аппликуха должна перечитать цены в момент жмякания "ОК", потому что они (цены!) могли измениться за то время, пока усер что-то там решал.

Гаджимурадов Рустам> Но откудова уверенность, что прочитанные N минут взад данные по ценам - еще сидят в кеше ?

Я разверну этот вопрос тебе же, сам над ним подумай
и доложи сюда ответ, а то аж позоришься. :-) Ей Богу,
даже подсказывать неудобно. Гы... вспомнилось: у нас в институте курс был, История КПСС и М-Л философия (нахрена он был нужен технарям - другой вопрос). И вёл его препод, которому задаёшь вопрос "а как вы объясните то-то", а он: "я бы поставил вопрос по-другому", "ваш вопрос слишком второстепенен", "сходите в деканат, там вам всё объяснят" (с занесением в учетную карточку комсомольца :)), "как вы в иинститут попали ?! вам не стыдно задавать такие глупые вопросы ?" или вообще: "а какой ответ вы ожидаете услышать?"

Объясни только вот это, плз:откудова уверенность, что прочитанные N минут взад данные по ценам - еще сидят в кеше ?

Гаджимурадов Рустампрочитанные N минут критичные данные <...> всегда перечитываютсяну, и ? вот тебе их надо перечитать - и что, они перед этой перечиткой всегда в кеше торчат, да ?