Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Microsoft SQL Server Новый топик    Ответить
Топик располагается на нескольких страницах: [1] 2   вперед  Ctrl      все
 Проблема с триггером  [new]
Ggest
Guest
Добрый день. Вообщем имеется таблица заказов (Orders) с атрибутами Id_Order, Amount (Сумма заказа) и таблица содержащая в себе Id_Dish(ид блюда) , Id_Order(id заказа), Number (количество заказанных блюд) и Cost (стоимость блюда с учетом количества).
Мне нужно написать триггер, чтобы сумма, формируемая из значений Cost была передана в Таблицу Orders атрибуту Amount. Например заказ 1, заказаны блюда 1 2 и 3 на суммы 100, 200 и 300. Итог 600. Нужно как то передать это значение заказу номер 1 в таблицу Orders
21 мар 18, 20:54    [21275749]     Ответить | Цитировать Сообщить модератору
 Re: Проблема с триггером  [new]
Andy_OLAP
Member

Откуда: я знаю, что Хапоэль Беэр-Шева - чемпион
Сообщений: 3151
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

Таки вот Вам мои мысли вслух.
+

Вставка строки заказа в таблицу строк - один триггер.
Изменение number или cost в строке заказа - другой триггер. Удаление строки из заказа - еще один триггер (ну или один триггер на все случаи жизни).
При этом триггер должен считать не только вставленную/измененную/удаленную строку из заказа, но все прочие строки этого же заказа, и сумму общую по всем строкам такого заказа пересчитанную - записать в Amount таблицы Orders.

Тут ведь какая загвоздка. ПО, которое работает с БД, вполне вероятно не знает о таких приколах. И пересчет стоимости блюда (взяли и подняли ценники на все салаты) приведет к изменению cost на всех строках всех заказов за период изменения, в которых есть салаты. А в это время еще один заказ, где был салат, редактируют, взяли и меняют количество блюд. Нужно подумать, как бы на блокировку не нарваться. Или разруливать такие блокировки. Или неудачные попытки по таймауту отвалившиеся.
21 мар 18, 23:16    [21275905]     Ответить | Цитировать Сообщить модератору
 Re: Проблема с триггером  [new]
SIMPLicity_
Member

Откуда: (((@)))
Сообщений: 8644
Вопрос к автору: триггер вешаем на какую таблицу и при каких условиях должен срабатывать?
PS Мне кажется в принципе некорректной постановка задачи. Триггер можно повесить либо на первую либо на вторую таблицу. Это, например, зависит от порядка вставки записей в таблицу.
21 мар 18, 23:43    [21275971]     Ответить | Цитировать Сообщить модератору
 Re: Проблема с триггером  [new]
.Евгений
Member

Откуда:
Сообщений: 493
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

Подозреваю, что архитектурно решение не продумано. Возможно, ваши манипуляции с заказами/блюдами лучше обернуть в процедуры, заполняющие все необходимые поля, а прямую запись в таблицы исключить.
22 мар 18, 09:50    [21276298]     Ответить | Цитировать Сообщить модератору
 Re: Проблема с триггером  [new]
invm
Member

Откуда: Москва
Сообщений: 9128
Andy_OLAP
При этом триггер должен считать не только вставленную/измененную/удаленную строку из заказа, но все прочие строки этого же заказа, и сумму общую по всем строкам такого заказа пересчитанную - записать в Amount таблицы Orders.
Серьезно? Вы различаете sum() и, например, min() или max()? Или вам все едино?
22 мар 18, 10:27    [21276381]     Ответить | Цитировать Сообщить модератору
 Re: Проблема с триггером  [new]
invm
Member

Откуда: Москва
Сообщений: 9128
Ggest,

Примерно так:
create trigger ...
on [таблица содержащая в себе]
after insert, update, delete
as
begin
 set nocount on;

 with s as
 (
  select
   id_Order, sum(Amount) as Amount
  from
   (
    select id_Order, Cost * Number from inserted
    union all
    select id_Order, -Cost * Number from deleted
   ) t (id_Order, Amount)
  group by
   id_Order
 )
 update o
  set
   Amount += s.Amount
 from
  s join
  Orders o on o.id_Order = s.id_Orderd;
end;
22 мар 18, 10:37    [21276411]     Ответить | Цитировать Сообщить модератору
 Re: Проблема с триггером  [new]
ПаWWWлОдАрЕц
Member

Откуда: NSK-PVL
Сообщений: 135
Ggest
Мне нужно написать триггер

Это вы так сами решили или вам так сказали сделать?
А если отказаться от триггеров?
На месте ТСа, я бы использовал более "ламповый" метод в виде отдельной (или нескольких) ХП, которые инкапсулируют всю логику внутри себя.
22 мар 18, 10:47    [21276451]     Ответить | Цитировать Сообщить модератору
 Re: Проблема с триггером  [new]
Владислав Колосов
Member

Откуда:
Сообщений: 7403
Есть умельцы - на триггерах пишут всю бизнес-логику. А чё?
22 мар 18, 14:36    [21277641]     Ответить | Цитировать Сообщить модератору
 Re: Проблема с триггером  [new]
Andy_OLAP
Member

Откуда: я знаю, что Хапоэль Беэр-Шева - чемпион
Сообщений: 3151
invm
Andy_OLAP
При этом триггер должен считать не только вставленную/измененную/удаленную строку из заказа, но все прочие строки этого же заказа, и сумму общую по всем строкам такого заказа пересчитанную - записать в Amount таблицы Orders.
Серьезно? Вы различаете sum() и, например, min() или max()? Или вам все едино?

1. Серьезно.
2. Различаю.
3. Зависит от ситуацию. Есть 3 подварианта.
3.1. Все едино.
3.2. Что-то едино, что-то в разнобой.
3.3. Ничего не едино.

Еще вопросы, коллега?
22 мар 18, 15:07    [21277827]     Ответить | Цитировать Сообщить модератору
 Re: Проблема с триггером  [new]
Andy_OLAP
Member

Откуда: я знаю, что Хапоэль Беэр-Шева - чемпион
Сообщений: 3151
Владислав Колосов
Есть умельцы - на триггерах пишут всю бизнес-логику. А чё?

Это таки да. А потом бывают случаи. Когда переносят базу в архив, оставляют в боевой часть строк заказов и часть заголовков заказов (Orders), потом начинают что-либо исправлять - и оказывается, что автоматическая процедура "видит" строки, по которым заголовков уже нет. А триггеру нужно работать, он же не просто так написан.

Ну а дальше вообще случаи, когда нужно что-то задним числом переписать в ценникам строк заказов, но историческую сумму Amount - которую оплатил получатель заказа из нескольких блюд - уже не трогать. А триггеру нужно работать, он будет "трогать" все Amount.

В общем, жизнь на триггерах это некошерно, я тут с Вами полностью согласен.
22 мар 18, 15:10    [21277852]     Ответить | Цитировать Сообщить модератору
 Re: Проблема с триггером  [new]
invm
Member

Откуда: Москва
Сообщений: 9128
Andy_OLAP
1. Серьезно.
Пошли на принцип? Ну успехов.
Andy_OLAP
2. Различаю.
А я думаю, что нет. Или только визуально различаете. Иначе бы не было вот этих мыслей вслух - 21275905

Если приведенный пример не убедил, попробуйте на досуге поразмышлять - почему в индексированных представлениях допустимо использование sum(), но недопустимо min() и max().
22 мар 18, 16:01    [21278111]     Ответить | Цитировать Сообщить модератору
 Re: Проблема с триггером  [new]
.Евгений
Member

Откуда:
Сообщений: 493
invm,

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

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

P.S. В ваш триггер нужно добавить обработку Orders.Amount = Null.
22 мар 18, 17:18    [21278414]     Ответить | Цитировать Сообщить модератору
 Re: Проблема с триггером  [new]
TaPaK
Member

Откуда: Kiev
Сообщений: 6794
.Евгений,
не продолжайте

а потом в вашем магазине выключают свет и все раходятся и потом потные dba генерируют ваше "окончание заказа"
22 мар 18, 17:28    [21278459]     Ответить | Цитировать Сообщить модератору
 Re: Проблема с триггером  [new]
invm
Member

Откуда: Москва
Сообщений: 9128
.Евгений
Допустим, блюда добавляются в БД по одному (по мере ввода заказа), а не все сразу.
Для заказа из 10 блюд мы получим 10 Inserts + 10 Update.
Расчет суммы по окончании формирования заказа - 10 Inserts + 1 (Update+Select). Вероятно, это создаст меньшую нагрузку.
Допустим.
Согласно вашей логике, невозможно узнать сумму заказа не завершив его формирование. Это очень удобно.
.Евгений
P.S. В ваш триггер нужно добавить обработку Orders.Amount = Null.
Вам доподлинно известно, что Amount nullable?
22 мар 18, 17:38    [21278499]     Ответить | Цитировать Сообщить модератору
 Re: Проблема с триггером  [new]
.Евгений
Member

Откуда:
Сообщений: 493
invm
Допустим.
Согласно вашей логике, невозможно узнать сумму заказа не завершив его формирование. Это очень удобно.

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

А вам - что нет? Возможны оба варианта работы с Null, но согласитесь, что надо было указать хотя бы один.
TaPaK
.Евгений,
не продолжайте

а потом в вашем магазине выключают свет и все раходятся и потом потные dba генерируют ваше "окончание заказа"

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

P.S. Возможно, я вам когда-то наступил на ногу? Не припомню. Какая жалость...
22 мар 18, 17:53    [21278577]     Ответить | Цитировать Сообщить модератору
 Re: Проблема с триггером  [new]
TaPaK
Member

Откуда: Kiev
Сообщений: 6794
.Евгений,

т.е. не продолжаейте совсем


автор
А вам - что нет? Возможны оба варианта работы с Null, но согласитесь, что надо было указать хотя бы один.

так ведь и Amount,Cost не сказано, что число! а он с ними такое творит
22 мар 18, 17:57    [21278607]     Ответить | Цитировать Сообщить модератору
 Re: Проблема с триггером  [new]
invm
Member

Откуда: Москва
Сообщений: 9128
.Евгений
В БД - нет. В интерфейсе - да.
Да, это очень грамотно - считать сумму и в БД и в интерфейсе.
Интереснее станет потом, когда, допустим, уже после внедрения появятся правила расчета скидки по итоговой сумме, или какие-то ограничения по сумме, или еще что-то подобное.
И плевать, что придется дорабатывать и БД, и интерфейс. Главное - не пользоваться триггерами.
.Евгений
Возможны оба варианта работы с Null, но согласитесь, что надо было указать хотя бы один.
Вот я и указал - для случая, когда Amount not null.
22 мар 18, 18:28    [21278694]     Ответить | Цитировать Сообщить модератору
 Re: Проблема с триггером  [new]
Владислав Колосов
Member

Откуда:
Сообщений: 7403
А что это за бизнес-модель, где промежуточные наборы хранят на сервере? Клиент при таком раскладе будет спамить запросы на сервер. Не слишком здорово, наверное.
22 мар 18, 19:01    [21278737]     Ответить | Цитировать Сообщить модератору
 Re: Проблема с триггером  [new]
.Евгений
Member

Откуда:
Сообщений: 493
invm
Да, это очень грамотно - считать сумму и в БД и в интерфейсе.
Интереснее станет потом, когда, допустим, уже после внедрения появятся правила расчета скидки по итоговой сумме, или какие-то ограничения по сумме, или еще что-то подобное.

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

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

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

Честно признаюсь, что обычно не нахожу применения триггерам в своем аспекте проектирования систем. Но это не означает, что я ослеплен ненавистью к ним.
TaPaK
так ведь и Amount,Cost не сказано, что число! а он с ними такое творит

Вы настойчиво постите сомнительного рода комментарии к моим сообщениям. Быть может, мне довелось наступить вам не на ногу, а между?

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

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

Не клиент; скорее менеджер, официант и т.п.
22 мар 18, 20:08    [21278815]     Ответить | Цитировать Сообщить модератору
 Re: Проблема с триггером  [new]
invm
Member

Откуда: Москва
Сообщений: 9128
.Евгений
Я правильно понял, что вы бы расположили расчет и применение бизнес-правил в триггере?
Правильно.
.Евгений
Увеличивается время транзакции и блокировки;
Если не применять бизнес-правила в той же транзакции, то зачем нужны такие правила? А их применение в этой же транзакции любыми средствами увеличивает длительность транзакции.
.Евгений
Разнообразные проблемы с расчетом заказа по разным версиям бизнес-правил
Это проблема квалификации разработчика. Говнокод останется говнокодом, вне зависимости от типа модуля, в котором он расположен.
.Евгений
Я бы проектировал применение бизнес-правил как функцию (в идеале сервис программируемой бизнесами BRMS), которая бы читала свои настроечные таблицы
Что мешает применять эту функцию в триггере?
22 мар 18, 21:40    [21278938]     Ответить | Цитировать Сообщить модератору
 Re: Проблема с триггером  [new]
.Евгений
Member

Откуда:
Сообщений: 493
invm
Если не применять бизнес-правила в той же транзакции, то зачем нужны такие правила?

Мне сложно представить ситуацию, когда бизнес-правила нужны актуальными с точностью до транзакции. Я думаю, что в подавляющем большинстве случаев будет приемлема схема из нескольких последовательных транзакций:
Т1 Чтение бизнес-правил
-- Применение бизнес-правил к элементу заказа
Т2...Тn Запись элемента заказа
Tn+1 Фиксация заказа

invm
Это проблема квалификации разработчика. Говнокод останется говнокодом, вне зависимости от типа модуля, в котором он расположен.

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

Повторю свое мнение еще раз - это избыточные блокировки и избыточное слияние нескольких транзакций в одну, причем нарастающее снежным комом. Например, понадобится добавить логирование (например, чтобы найти источник ошибки: бизнес-правила, элемент, заказ) - это пойдет в триггер вместе со своими проблемами (многопоточная последовательная запись в таблицу лога), которые будут тормозить операцию в целом (в т.ч. блокировать таблицу заказов). У хп логирование можно как держать внутри, так и при необходимости вынести наружу (хп возвращает результат, который передается в служебную хп логирования).
22 мар 18, 22:51    [21279041]     Ответить | Цитировать Сообщить модератору
 Re: Проблема с триггером  [new]
invm
Member

Откуда: Москва
Сообщений: 9128
.Евгений
Мне сложно представить ситуацию, когда бизнес-правила нужны актуальными с точностью до транзакции. Я думаю, что в подавляющем большинстве случаев будет приемлема схема из нескольких последовательных транзакций:
Т1 Чтение бизнес-правил
-- Применение бизнес-правил к элементу заказа
Т2...Тn Запись элемента заказа
Tn+1 Фиксация заказа
Согласованность данных на протяжении от Т1 до Tn как будете обеспечивать? Не говоря уже о необходимости либо в T2 знать о примененности Т1, либо безусловно применять уже возможно примененное в Т1. В конечном итоге, такой подход приводит к необходимости наличия специальной инфраструктуры для обеспечения его корректного функционирования.
.Евгений
В хорошо спроектированном модуле сложно говнокодить
Говнокодить легко в любом месте. Достаточно следовать принципу "сделаю так, чтобы работало здесь и сейчас, а потом хоть трава не расти".
.Евгений
Повторю свое мнение еще раз - это избыточные блокировки и избыточное слияние нескольких транзакций в одну
Это с вашей точки зрения оно избыточное, с точки зрения согласованности данных вовсе не избыточное. А страх блокировок был оправдан пока не существовало способов избавится от клонфликтов "читатель-писатель".
.Евгений
Например, понадобится добавить логирование (например, чтобы найти источник ошибки: бизнес-правила, элемент, заказ) - это пойдет в триггер вместе со своими проблемами (многопоточная последовательная запись в таблицу лога)
Достаточно воспользоваться имеющимися возможностями по организации асинхронных операций, а не городить огород вида "У хп логирование можно как держать внутри, так и при необходимости вынести наружу (хп возвращает результат, который передается в служебную хп логирования)." и не боятся потом, что некий умник эту хп забудет вызвать.
23 мар 18, 11:58    [21280209]     Ответить | Цитировать Сообщить модератору
 Re: Проблема с триггером  [new]
.Евгений
Member

Откуда:
Сообщений: 493
invm
Согласованность данных на протяжении от Т1 до Tn как будете обеспечивать? Не говоря уже о необходимости либо в T2 знать о примененности Т1, либо безусловно применять уже возможно примененное в Т1. В конечном итоге, такой подход приводит к необходимости наличия специальной инфраструктуры для обеспечения его корректного функционирования.

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

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

Категорически не соглашусь. На основе моего опыта считаю, что обойтись без говнокода в относительно маленькой и локализованной задаче значительно проще, чем в относительно большой и сцепленной с кучей посторонних модулей. Те же микросервисы придуманы не просто так. Впрочем, я не стану вас переубеждать, обычно это неблагодарное занятие.
invm
Это с вашей точки зрения оно избыточное, с точки зрения согласованности данных вовсе не избыточное.

Незафиксированный заказ не требует полной внутренней согласованности. Очень транзакционно, замечу.
invm
Достаточно воспользоваться имеющимися возможностями по организации асинхронных операций, а не городить огород ... и не боятся потом, что некий умник эту хп забудет вызвать.

Вы говорите про сервис брокер? Это еще одна потенциальная точка отказа и дополнительная нагрузка на сервер (вместо одного insert).
Как же, как же, помню я одно свое устройство на работу, где первый заданный вопрос мне был, имею ли я опыт работы с брокером, а то что-то в нем на бою завалилось.
Дополнительный вызов логирования без труда инкапсулируется внутри слоя взаимодействия с БД, после чего проблема забывчивости полностью теряет свою остроту.
23 мар 18, 13:19    [21280564]     Ответить | Цитировать Сообщить модератору
 Re: Проблема с триггером  [new]
invm
Member

Откуда: Москва
Сообщений: 9128
.Евгений
Собственно, запихивая бизнес-логику в триггер, вы заставляете ее выполниться в БД для каждого элемента.
Именно. Или для всех сразу. Независимо от желаний и склероза пишущих код, обеспечивая тем самым ее безусловную проверку и откат транзакции если это потребуется.
.Евгений
Впрочем, я не стану вас переубеждать, обычно это неблагодарное занятие.
Вот-вот, и я аналогично.
.Евгений
Незафиксированный заказ не требует полной внутренней согласованности.
Это всего лишь ваше частное мнение.
.Евгений
Вы говорите про сервис брокер? Это еще одна потенциальная точка отказа и дополнительная нагрузка на сервер (вместо одного insert).
Само собой. Зато разнообразные "слои для работы с БД" и т.п., компенсирующие незнание разработчиком матчасти, это не точки отказа.
Никогда не понимал стонов о производительности людей, которые без зазрения совести выгребают и обрабатывают данные в столь любимых ими "слоях" или напрямую в интерфейсе, когда можно было бы прекрасно обойтись только средствами БД.
.Евгений
Дополнительный вызов логирования без труда инкапсулируется внутри слоя взаимодействия с БД, после чего проблема забывчивости полностью теряет свою остроту.
До первого случая, когда потребуется работать с БД мимо "слоя взаимодействия с БД".
23 мар 18, 15:56    [21281267]     Ответить | Цитировать Сообщить модератору
 Re: Проблема с триггером  [new]
.Евгений
Member

Откуда:
Сообщений: 493
invm
Именно. Или для всех сразу. Независимо от желаний и склероза пишущих код, обеспечивая тем самым ее безусловную проверку и откат транзакции если это потребуется.

Эта независимость прекрасно решается ограничением прямого доступа к таблицам, работой с данными только через слой хп и т.п.
invm
До первого случая, когда потребуется работать с БД мимо "слоя взаимодействия с БД".

Я не понимаю, что именно вы хотели сказать. Может быть, вы собрались работать мимо всех слоев OSI выше канального? Давайте не будем считать самоцелью непосредственный доступ к низкоуровневым объектам. Такой доступ обычно требуется, когда архитектура системы закрывает нужные потребителю объекты или значимо замедляет его работу. Допустим, слой хп закрывает запись в таблицы. Однако, как я показал выше, триггер может тормозить ее.
invm
.Евгений
Незафиксированный заказ не требует полной внутренней согласованности.
Это всего лишь ваше частное мнение.

Вы подчеркнули это так, словно готовы сослаться на признанного авторитета или безукоризненно логичное рассуждение, обосновывающее противоположную позицию. Нет?
invm
Само собой. Зато разнообразные "слои для работы с БД" и т.п., компенсирующие незнание разработчиком матчасти, это не точки отказа.
Никогда не понимал стонов о производительности людей, которые без зазрения совести выгребают и обрабатывают данные в столь любимых ими "слоях" или напрямую в интерфейсе, когда можно было бы прекрасно обойтись только средствами БД.

Я понимаю крик вашей души. Более того, испытываю соблазн усесться рядом и тоже выплакаться на тему того, как мои коллеги парсят хмл из полутора тегов десериализацией. Потом добавить, что управляемый код - это полная лажа и тормоз коммунизма, зато ассемблер - это круто, привести тому собственноручно написанные примеры, обняться и поделиться жилетками.
Однако потом я вспоминаю, что живу в реальном мире, где пони не какают радугой. Что если я всерьез наеду на вышеупомянутых коллег, то мне придется делать работу за них. Что моя цель - не абсолютная оптимизация, а работающее решение, поэтому оптимизировать нужно лишь то, что этому мешает. Что ресурсы локальных компов пользователей в разумных пределах - дармовые (говорю про обычные пк). Что экономить в первую очередь нужно ресурсы БД и серверов, ибо масштабирование обязательно заставит обратить на них внимание, и лучше позже, чем раньше. Проблемы с серверными ресурсами будут общими проблемами, проблемы клиентской части - только ее разработчиков, сколько бы там ни было промежуточных слоев - хоть один, хоть тысяча и один (меньше одного не будет, в этом я абсолютно уверен). Поэтому я разменяю вызов хп логирования на какой-нибудь желаемый фронтовиками формат хмл и буду чувствовать себя вполне удовлетворенным.
25 мар 18, 23:11    [21284753]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: [1] 2   вперед  Ctrl      все
Все форумы / Microsoft SQL Server Ответить