Хранение SQL-запросов в таблице на сервере SQL

Question

У нас есть несколько рабочих мест в нашей системе. Эти работы перечислены в сетке. У нас есть 3 разных типа пользователей (usertypeid 1,2,3). Для каждого пользователя листинг отличается, и он может фильтровать листинг, выбрав вид из выпадающего списка. ViewName в приведенной ниже таблице - это вид, который необходимо отобразить. Для достижения этой функциональности один из разработчиков создал следующую структуру таблицы и сохранил фрагменты sql в SQLExpression в таблице ниже. По моему мнению, запрос не должен храниться в базе данных. Каковы плюсы и минусы этого подхода и каковы доступные альтернативы?

JobListingViewID         ViewName        SQLExpression            UserTypeID
 3                     All Jobs            1 = 1                       3
 4                     Error Jobs   JobStatusID IN ( 2 )               1
 5                     Error Jobs   JobStatusID IN ( 2 )               2
 6                     Error Jobs   JobStatusID IN ( 2 )               3
 7                     Speech       JobStatusID IN ( 1, 3, 8 )         1

Answer 1

Недостатки: 1. Боль поддерживать. 2. Нет оптимизации (кеширование и т. Д.). 3. Изменение имен объектов означает, что вам придется изменить данные в этой таблице. Это нормально для нескольких записей, но как только таблица расширится, вы будете тратить больше времени на ее обслуживание.

Answer 2

Вам просто нужно иметь матричную таблицу из ViewName UserTypeID JobStatusID комбинаций, а затем присоединиться к ней в своем запросе. Вам не нужен динамический SQL и дополнительный поиск в БД.

NB. Для просмотра "Все вакансии" у вас должен быть просто другой запрос, который отказывается от JOIN. Это сэкономит немного ненужной обработки и означает, что при добавлении нового задания вам не нужно настраивать разрешения. В остальном используйте матрицу, подобную приведенной ниже.

ViewName        JobStatusID        UserTypeID
Error Jobs             2                1
Error Jobs             2                2
Error Jobs             2                3
Speech                 1                1
Speech                 3                1
Speech                 8                1

Answer 3

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