применение бизнес-правил на уровне базы данных

Question

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

Например,

if a person is part of group X 
and (if they have attribute O) has either attribute P or attribute Q, 
or (if they don't have attribute O) has attribute P but not Q,
and don't have attribute R, 
and aren't part of group Y (unless they also are part of group Z), 
then status A is true. 

Умножить на несколько десятков статусов и, возможно, сотни групп и атрибутов.Люди, группы и атрибуты находятся в базе данных.

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

Таким образом, наш текущий план проектирования должен иметь таблицу или представление, состоящее из набора логических флагов (hasStatusA? hasStatusB? hasStatusC?) для каждогочеловек.Таким образом, если я хочу сделать запрос для всех, кто имеет статус C, мне не нужно знать все правила для вычисления статуса C;Я просто проверяю флаг.

(обратите внимание, что в реальной жизни флаги будут иметь более значимые имена: isElptableForReview ?, isPastDueForReview? И т. Д.).

Итак, а) эторазумный подход, и б) если так, каков наилучший способ вычисления этих флагов?

Некоторые варианты, которые мы рассматриваем для вычисления флагов:

1. Создайте набор изпомечает представление и вычисляет значения флага из базовых данных в режиме реального времени, используя SQL или PL-SQL (это БД Oracle).Таким образом, значения всегда точны, но производительность может пострадать, и разработчик должен будет поддерживать правила.

2. Сделать набор флагов состоящим из статических данных и использовать некоторыетип механизма правил, чтобы поддерживать эти флаги в актуальном состоянии при изменении базовых данных.Таким образом, правила могут поддерживаться легче, но флаги могут быть неточными в данный момент времени.(Если мы пойдем с этим подходом, есть ли механизм правил, который может легко манипулировать данными в базе данных таким образом?)

Answer 1

В таком случае я предлагаю применить вопрос Уорда Каннингема - задайте себе вопрос: «Какая самая простая вещь, которая могла бы сработать?».

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

Делись и наслаждайся.

Answer 2

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

Однако функция может работать недостаточно хорошо, если вы вызываете его для нескольких строк одновременно (например, для отчетов).Таким образом, если вы используете Oracle 11g, вы можете решить эту проблему, добавив виртуальные столбцы (поиск "виртуальный столбец") в соответствующие таблицы на основе функции.Функция Result Cache также должна повысить производительность функции.

Answer 3

Я бы посоветовал не делать статусы именами столбцов, а использовать идентификатор и значение статуса. например, таблица статуса клиента со столбцами идентификатора и значения.

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

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