Использование триггера базы данных - лучшие практики

Question

Краткая справка:

В настоящее время у меня есть пятнадцатилетняя система управления запасами.В попытке обеспечить количество в реальном времени как для отдельных предметов, так и для комплектов (возможно, вложенных до N-го уровня), инвентарь распределяется на заказы на лету, когда запрашивается страница (приоритет распределения определяется датой получения и датойожидается).В зависимости от того, сколько заказов в системе и, в частности, сколько из этих заказов содержит вложенные наборы, производительность может быть проблемой.

Вопрос (ы):

В настоящее время мы разрабатываем новую систему управления запасами с использованием принципов SOA.Вместо того, чтобы размещать инвентарь на лету, мы бы хотели, чтобы таблица распределения обновлялась после каждой вставки, обновления и удаления, которые могут повлиять на данные распределения элементов.Есть некоторые споры относительно того, должна ли таблица размещения обновляться триггерами в БД или службой заказов C #.

• Какой метод лучше всего будет соответствовать принципам SOA?
• Какой метод был бы более производительным?
• Является ли это правильным использованием триггера?
• Является ли какой-либо из методов общепринятым для сообщества в целом как "правильный способ сделать что-то"?

Заранее спасибо за ваше время!

Answer 1

Я думаю, что 3 других ответа от HLGEM, Jimbo, Joel Brown все верны.

Просто чтобы ответить на каждый ваш конкретный вопрос

Какой метод лучше всего соответствует принципам SOA?

Либо зависит от остальной части вашей архитектуры. Сколько у вас других систем? Нужны ли этим другим системам прямой доступ к БД или они обращаются к БД через этот сервис?

Какой метод будет более производительным?

Нет никакой разницы в любом случае.

Это правильное использование триггера?

Да

Является ли какой-либо из методов общепринятым для сообщества в целом как "правильный способ сделать что-то"?

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

Answer 2

Я думаю, что это сводится к старой религиозной войне за то, иметь ли какую-либо бизнес-логику в TSQL (хранимые процессы или триггеры). Некоторые люди любят вводить как можно больше логики в слой базы данных, в то время как другие думают, что это худшее, что вы можете сделать.

Посмотрите на этот вопрос , чтобы обсудить различные плюсы и минусы. Какой аргумент вы считаете наиболее убедительным - это путь, по которому вы должны идти.

Answer 3

Триггеры - единственное решение, где вы можете гарантировать, что данные будут синхронизированы.Вы не можете гарантировать, что значения не будут изменены на лету за пределами приложения (скажем, для устранения проблемы с большими данными), поэтому триггер является единственным правильным решением.

Answer 4

Если вставка, обновление и удаление выполняются с помощью хранимых процедур, то таблица распределения также должна обновляться внутри этих хранимых процедур - это было бы идеальным решением.

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