mandarinaupdate zakaz set zakaz.summa=:tovar.cena +dostavka.cena.+sborka.cena
where id_zakaza=:id_zak;Выделенные значения надо тоже передать в эту ХП в кач-ве входных аргументов.

Гаджимурадов РустамКстати, да, Таблоид прав, там же отдельные поля.
Только передавать надо, конечно, не доп.параметры,
а 1 параметр id_zakaza, а по нему вытаскивать остальные
id_товара, id_доставки, id_сборки и по ним фильтровать.да, это правильнее.
Но если в "вызывателе" уже есть id_доставки и id_сборки, то зачем дёргать таблицы лишний раз ? Лучше тогда вообще передавать эти параметры как необязательные и разрулить в ХП эту ситуацию через if-else.

Гаджимурадов Рустамплохой дизайн. Но с т.з. произв-ти, да, лучше.я знаю, что "чем умнее ХП, тем хуже для неё". Но после многочисленных замеров прошлого года, связанных с имитацией олтп-грузилова, убедился, что чем меньше лазишь на диск, тем крепче сон :-)

Гаджимурадов РустамТаблоид> я знаю, что "чем умнее ХП, тем хуже для неё"

Ничего подобного. Это правило для триггеров.Это универсальное правило: чем меньше модуль знает об окружающем мире, тем проще будет его код. И тем спокойнее будет жазнь аффтара этого кода.

Гаджимурадов РустамА теперь покрути в
голове эту ситуацию с т.з. триггера, ХП и кеша - в
любом раскладе твой вариант худший из возможных. :)Не понял тут, поясни плз. Что значит "с т.з. триггера, ХП и кеша", особенно про кеш ?

Гаджимурадов Рустам> Не понял тут, поясни плз. Что значит "с т.з. триггера, ХП и кеша", особенно про кеш ?

Ну кеш - это про твоё "диск". А "триггер vs ХП" -
это второй вариант, без кеша. Третий - твой.Извиняй, но всё равно не понимать я что-то по русськи :-)
Вот это вот:ГРв любом раскладе твой вариант худший из возможных- обоснуй детально, плз.
Чем вот такое вот:

... пардон, коммит был раньше положенного...
ну так вот: чем этот вариант "худший из возможных" ?

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

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

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

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

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

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

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

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

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

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

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