GgestДобрый день. Вообщем имеется таблица заказов (Orders) с атрибутами Id_Order, Amount (Сумма заказа) и таблица содержащая в себе Id_Dish(ид блюда) , Id_Order(id заказа), Number (количество заказанных блюд) и Cost (стоимость блюда с учетом количества).
Мне нужно написать триггер, чтобы сумма, формируемая из значений Cost была передана в Таблицу Orders атрибуту Amount. Например заказ 1, заказаны блюда 1 2 и 3 на суммы 100, 200 и 300. Итог 600. Нужно как то передать это значение заказу номер 1 в таблицу Orders
Подозреваю, что архитектурно решение не продумано. Возможно, ваши манипуляции с заказами/блюдами лучше обернуть в процедуры, заполняющие все необходимые поля, а прямую запись в таблицы исключить.

invm,

Допустим, блюда добавляются в БД по одному (по мере ввода заказа), а не все сразу.
Для заказа из 10 блюд мы получим 10 Inserts + 10 Update.
Расчет суммы по окончании формирования заказа - 10 Inserts + 1 (Update+Select). Вероятно, это создаст меньшую нагрузку.

То же самое при отмене (как-то раз наблюдал в кассе супермаркета последовательную отмену заказа из нескольких десятков позиций).

P.S. В ваш триггер нужно добавить обработку Orders.Amount = Null.

invmДопустим.
Согласно вашей логике, невозможно узнать сумму заказа не завершив его формирование. Это очень удобно.
В БД - нет. В интерфейсе - да.
invm.ЕвгенийP.S. В ваш триггер нужно добавить обработку Orders.Amount = Null.Вам доподлинно известно, что Amount nullable?
А вам - что нет? Возможны оба варианта работы с Null, но согласитесь, что надо было указать хотя бы один.
TaPaK.Евгений,
не продолжайте

а потом в вашем магазине выключают свет и все раходятся и потом потные dba генерируют ваше "окончание заказа"
Запах перезаводящих заказы с нуля потных менеджеров вам нравится больше. Что ж, каждому свое.

P.S. Возможно, я вам когда-то наступил на ногу? Не припомню. Какая жалость...

invmДа, это очень грамотно - считать сумму и в БД и в интерфейсе.
Интереснее станет потом, когда, допустим, уже после внедрения появятся правила расчета скидки по итоговой сумме, или какие-то ограничения по сумме, или еще что-то подобное.
Я правильно понял, что вы бы расположили расчет и применение бизнес-правил в триггере?
Мне кажется это неправильным по следующим причинам (навскидку):
- Увеличивается время транзакции и блокировки;
- Разнообразные проблемы с расчетом заказа по разным версиям бизнес-правил (начали по одной, продолжили по другой; необходимость перерасчета и др.)

Они в принципе решаемы, но результат выглядит для меня экстремальной порнографией.

Я бы проектировал применение бизнес-правил как функцию (в идеале сервис программируемой бизнесами BRMS) , которая бы читала свои настроечные таблицы, но никак не касалась данных заказов; к которой обращались бы и приложение, и хп фиксации заказа; на входе которой ожидались параметры заказа, а возвращались - коэффициенты и модификаторы.
invmГлавное - не пользоваться триггерами.
Честно признаюсь, что обычно не нахожу применения триггерам в своем аспекте проектирования систем. Но это не означает, что я ослеплен ненавистью к ним.
TaPaKтак ведь и Amount,Cost не сказано, что число! а он с ними такое творит
Вы настойчиво постите сомнительного рода комментарии к моим сообщениям. Быть может, мне довелось наступить вам не на ногу, а между?

В стартовом сообщении значения полей Amount и Cost заданы числовыми, над ними выполняются арифметические операции. Кроме того, смысл понятий "сумма заказа" и "стоимость блюда" подразумевает их числово-денежное наполнение. Это очевидное, разумное и достаточное основание для того, чтобы считать указанные поля числовыми.

В то же время не было никаких аналогичных оснований для ограничения Amount not null вплоть до ответа invm на мое сообщение об этом.
Владислав КолосовА что это за бизнес-модель, где промежуточные наборы хранят на сервере? Клиент при таком раскладе будет спамить запросы на сервер. Не слишком здорово, наверное.
Не клиент; скорее менеджер, официант и т.п.

invmЕсли не применять бизнес-правила в той же транзакции, то зачем нужны такие правила?
Мне сложно представить ситуацию, когда бизнес-правила нужны актуальными с точностью до транзакции. Я думаю, что в подавляющем большинстве случаев будет приемлема схема из нескольких последовательных транзакций:
Т1 Чтение бизнес-правил
-- Применение бизнес-правил к элементу заказа
Т2...Тn Запись элемента заказа
Tn+1 Фиксация заказа
invmЭто проблема квалификации разработчика. Говнокод останется говнокодом, вне зависимости от типа модуля, в котором он расположен.
Не согласен. Эта проблема в первую очередь архитектора, отвечающего за такие характеристики модуля, как зацепление и связность. В хорошо спроектированном модуле сложно говнокодить и легко вычищать говнокод. Именно по этой причине я отстаиваю отделение бизнес-правил от записи элементов заказа, а тех, в свою очередь, от записи заказа целиком; говнокод в одном месте не скажется на другом.
invm.ЕвгенийЯ бы проектировал применение бизнес-правил как функцию (в идеале сервис программируемой бизнесами BRMS) , которая бы читала свои настроечные таблицыЧто мешает применять эту функцию в триггере?
Повторю свое мнение еще раз - это избыточные блокировки и избыточное слияние нескольких транзакций в одну, причем нарастающее снежным комом. Например, понадобится добавить логирование (например, чтобы найти источник ошибки: бизнес-правила, элемент, заказ) - это пойдет в триггер вместе со своими проблемами (многопоточная последовательная запись в таблицу лога), которые будут тормозить операцию в целом (в т.ч. блокировать таблицу заказов). У хп логирование можно как держать внутри, так и при необходимости вынести наружу (хп возвращает результат, который передается в служебную хп логирования).

invmСогласованность данных на протяжении от Т1 до Tn как будете обеспечивать? Не говоря уже о необходимости либо в T2 знать о примененности Т1, либо безусловно применять уже возможно примененное в Т1. В конечном итоге, такой подход приводит к необходимости наличия специальной инфраструктуры для обеспечения его корректного функционирования.
Не очень понял суть вопроса.
Поясню еще раз предлагаемый мной вариант: при открытии нового заказа в клиентское ПО ими сравнивается и при необходимости обновляется набор бизнес-правил (способ непринципиален: набор формул, функция SQL в локальную БД, подключаемая DLL и т.п.) - это Т1. Далее клиентское ПО вносит в БД элементы заказа согласно этому набору (Т2...Тn). Наконец, по окончании ввода происходит фиксация, выполняющая проверки (в т.ч. версий бизнес-правил) и при необходимости - пересчет заказа (Тn+1).

Собственно, запихивая бизнес-логику в триггер, вы заставляете ее выполниться в БД для каждого элемента. А я предлагаю сделать всего один раз (локальные выполнения на БД не влияют) . Да и сомневаюсь я, что при развитой бизнес-логике возможно обойтись без фиксации, одним только триггером с inserted+deleted. А если невозможно, то триггер не нужен.
invmГовнокодить легко в любом месте. Достаточно следовать принципу "сделаю так, чтобы работало здесь и сейчас, а потом хоть трава не расти".
Категорически не соглашусь. На основе моего опыта считаю, что обойтись без говнокода в относительно маленькой и локализованной задаче значительно проще, чем в относительно большой и сцепленной с кучей посторонних модулей. Те же микросервисы придуманы не просто так. Впрочем, я не стану вас переубеждать, обычно это неблагодарное занятие.
invmЭто с вашей точки зрения оно избыточное, с точки зрения согласованности данных вовсе не избыточное.
Незафиксированный заказ не требует полной внутренней согласованности. Очень транзакционно, замечу.
invmДостаточно воспользоваться имеющимися возможностями по организации асинхронных операций, а не городить огород ... и не боятся потом, что некий умник эту хп забудет вызвать.
Вы говорите про сервис брокер? Это еще одна потенциальная точка отказа и дополнительная нагрузка на сервер (вместо одного insert).
Как же, как же, помню я одно свое устройство на работу, где первый заданный вопрос мне был, имею ли я опыт работы с брокером, а то что-то в нем на бою завалилось.
Дополнительный вызов логирования без труда инкапсулируется внутри слоя взаимодействия с БД, после чего проблема забывчивости полностью теряет свою остроту.

invmИменно. Или для всех сразу. Независимо от желаний и склероза пишущих код, обеспечивая тем самым ее безусловную проверку и откат транзакции если это потребуется.
Эта независимость прекрасно решается ограничением прямого доступа к таблицам, работой с данными только через слой хп и т.п.
invmДо первого случая, когда потребуется работать с БД мимо "слоя взаимодействия с БД".
Я не понимаю, что именно вы хотели сказать. Может быть, вы собрались работать мимо всех слоев OSI выше канального? Давайте не будем считать самоцелью непосредственный доступ к низкоуровневым объектам. Такой доступ обычно требуется, когда архитектура системы закрывает нужные потребителю объекты или значимо замедляет его работу. Допустим, слой хп закрывает запись в таблицы. Однако, как я показал выше, триггер может тормозить ее.
invm.ЕвгенийНезафиксированный заказ не требует полной внутренней согласованности.Это всего лишь ваше частное мнение.
Вы подчеркнули это так, словно готовы сослаться на признанного авторитета или безукоризненно логичное рассуждение, обосновывающее противоположную позицию. Нет?
invmСамо собой. Зато разнообразные "слои для работы с БД" и т.п., компенсирующие незнание разработчиком матчасти, это не точки отказа.
Никогда не понимал стонов о производительности людей, которые без зазрения совести выгребают и обрабатывают данные в столь любимых ими "слоях" или напрямую в интерфейсе, когда можно было бы прекрасно обойтись только средствами БД.
Я понимаю крик вашей души. Более того, испытываю соблазн усесться рядом и тоже выплакаться на тему того, как мои коллеги парсят хмл из полутора тегов десериализацией. Потом добавить, что управляемый код - это полная лажа и тормоз коммунизма, зато ассемблер - это круто, привести тому собственноручно написанные примеры, обняться и поделиться жилетками.
Однако потом я вспоминаю, что живу в реальном мире, где пони не какают радугой. Что если я всерьез наеду на вышеупомянутых коллег, то мне придется делать работу за них. Что моя цель - не абсолютная оптимизация, а работающее решение, поэтому оптимизировать нужно лишь то, что этому мешает. Что ресурсы локальных компов пользователей в разумных пределах - дармовые (говорю про обычные пк). Что экономить в первую очередь нужно ресурсы БД и серверов, ибо масштабирование обязательно заставит обратить на них внимание, и лучше позже, чем раньше. Проблемы с серверными ресурсами будут общими проблемами, проблемы клиентской части - только ее разработчиков, сколько бы там ни было промежуточных слоев - хоть один, хоть тысяча и один (меньше одного не будет, в этом я абсолютно уверен). Поэтому я разменяю вызов хп логирования на какой-нибудь желаемый фронтовиками формат хмл и буду чувствовать себя вполне удовлетворенным.