Мы хотим написать некоторые правила бизнес-логики, которые работают над определенными данными для создания отчетов. Не уверен, что лучше всего хранить их в базе данных MySQL.
Он может иметь цепочку правил, а затем инструкцию для результата, как показано выше.
Для создания отчетов вы можете конвертировать бизнес-логику на любом языке программирования. И используйте данные базы данных для генерации отчетов.
Против бизнес-логики, хранящейся в базе данных
Я помещаю большое значение в силу выражения, и я не нахожу SQL-пространство - это все, что выразительно. Используйте лучшие инструменты, которые у вас есть. для наиболее подходящих задач. Поворот с логикой и выше лучше всего на высшем уровне. Вследствие этого, хранение и массовая обработка данных лучше всего выполнять на уровне сервера, вероятно, в хранимых процедурах.
Но это зависит. Если у вас несколько приложений, взаимодействующих с одним механизм хранения, и вы хотите убедиться, что он поддерживает свою целостность и рабочий процесс, тогда вы должны разгрузить всю логику в сервер базы данных. Или, будьте готовы управлять параллельной разработкой в нескольких приложений.
Источник: Аргументы для/против бизнес-логики в хранимых процедурах
См. также:
CREATE TABLE businessRule (
id INT NOT NULL ,
name VARCHAR(32) NOT NULL ,
description VARCHAR(255) NULL ,
statement VARCHAR(255) NOT NULL ,
PRIMARY KEY (id) )
ENGINE = InnoDB;
CREATE TABLE leftOperand (
id INT NOT NULL ,
value VARCHAR(255) NOT NULL ,
PRIMARY KEY (id) )
ENGINE = InnoDB;
CREATE TABLE ruleItem (
id INT NOT NULL ,
businessRuleId INT NOT NULL ,
operator ENUM('if','and','or','not') NOT NULL ,
loperand INT NOT NULL ,
comparator ENUM('<','=','>') NOT NULL ,
roperand VARCHAR(255) NOT NULL ,
roperand_ispercentage TINYINT(1) NOT NULL ,
PRIMARY KEY (id) ,
INDEX businessRule_FK (businessRuleId ASC) ,
INDEX leftOperand_FK (loperand ASC) ,
CONSTRAINT businessRule_FK
FOREIGN KEY (businessRuleId )
REFERENCES mydb.businessRule (id )
ON DELETE CASCADE
ON UPDATE RESTRICT,
CONSTRAINT leftOperand_FK
FOREIGN KEY (loperand )
REFERENCES mydb.leftOperand (id )
ON DELETE RESTRICT
ON UPDATE RESTRICT)
ENGINE = InnoDB;
Аргумент против бизнес-логики "мягкого кодирования" следующим образом: http://thedailywtf.com/Articles/Soft_Coding.aspx
"Причина, по которой мы находим" Мягкое кодирование ", состоит в том, что мы боимся перемен. Не нормальный Страх перемен, но страх, что код, который мы пишем, должен измениться в результате изменения бизнес-правила. страх иметь. Весь смысл программного обеспечения (следовательно," мягкий ") заключается в том, что он может измениться, что он изменится. Единственный способ изолировать ваше программное обеспечение от изменений бизнес-правил - это создать полностью общую программу, лишенную всех бизнес-функций правила еще могут реализовать любое правило.О, и они уже создали этот инструмент, его называли С++, а Java, а С# и Basic. И, смею сказать, COBOL."
Все, что я могу вам дать, - это то, как вы должны решить эту проблему, а не сам ответ.
Общий способ создания базы данных для хранения сложных данных, как это, заключается в том, чтобы создать способ сохранить их в памяти как объекты, а затем попытаться создать базу данных соответственно. В конце концов, вы будете оценивать правила на языке программирования. Процедура будет следующей: сначала диаграмма классов
Затем пришло время преобразовать его в ERD:
Когда у вас есть структура базы данных для хранения/перезагрузки вашего объекта в/из, вы можете просто создать свои классы, чтобы каждый объект отвечал за загрузку/хранение себя.
[ОБНОВЛЕНИЕ]
Например, если вы хотите сохранить оператор a + b * -c в базе данных, его можно перевести как следующие вставки:
-- c
INSERT INTO statement (statement_id) VALUES (1);
INSERT INTO operand (statement_id, type) VALUES (1, 'double');
-- - (minus)
INSERT INTO statement (statement_id) VALUES (2);
INSERT INTO operator (statement_id, type) VALUES (2, 'minus');
-- -c
INSERT INTO binary (operator_statement_id, operand_statement_id) VALUES (2, 1);
-- b
INSERT INTO statement (statement_id) VALUES (3);
INSERT INTO operand (statement_id, type) VALUES (3, 'double');
-- * (multiply)
INSERT INTO statement (statement_id) VALUES (4);
INSERT INTO operator (statement_id, type) VALUES (4, 'multiply');
-- b * -c
INSERT INTO unary (operator_statement_id, operand_statement_id1, operand_statement_id2) VALUES (4, 3, 2);
-- a
INSERT INTO statement (statement_id) VALUES (5);
INSERT INTO operand (statement_id, type) VALUES (5, 'double');
-- + (plus)
INSERT INTO statement (statement_id) VALUES (6);
INSERT INTO operator (statement_id, type) VALUES (6, 'sum');
-- a + b * -c
INSERT INTO unary (operator_statement_id, operand_statement_id1, operand_statement_id2) VALUES (6, 5, 4);
Итак, если я правильно понимаю, вы хотите использовать переднюю часть, чтобы позволить людям динамически создавать логику, которая будет применяться к запросам (динамически построены, где клаузулы во время выполнения, на основе которых используются правила)?
Если это так, вам нужно быть достаточно конкретным в отношении того, какие условия они могут выбрать в своих правилах (изменение в каком значении (столбце), чтобы они могли иметь только условные правила против столбцов, существующих в наборе данных, который вы сообщаете от).
Если я правильно понимаю ваш вопрос, я бы начал с определения того, какие таблицы/столбцы вы хотите, чтобы они могли выбирать условия. Это будет ваш контроль над веб-страницей для разработки правил.
Однако, если вы просто спрашиваете, как сохранить правила после их выбора в базе данных, я бы предложил сохранить его в одной таблице, содержащей:
ID | RuleSetName | Table | Column | Comparison | Value | Percentage | Notes | CreatedDate | Created By
1 | 'VisitorAnalytics' | Visitors | SUM(Views) | > | null | 10 | n/a | 1/1/2012 | JohnDoe
Затем, как только эти записи будут созданы, вы будете использовать их, введя таблицы в предложение from, столбцы в предложение where для вашего динамического sql.
Я знаю, это может показаться запутанным, но то, что вы просите, является довольно сложным решением. Но в конечном итоге вы просто хотите сохранить правила вместе в одном месте, где вы можете циклически выполнить динамическую сборку, а затем выполнить SQL для генерации отчета. Надеюсь, это указывает на то, что вы в правильном направлении.
Я думаю, что сначала нужно решить, нужно ли вам сначала вводить правила в базу данных.
Базы данных представляют собой тяжелое решение и часто просто не нужны.
Имея дело с механизмами правил в различных формах, включая базу данных, я могу сказать, что она может стать действительно разочаровывающей и непродуктивной, очень быстро. Одна из больших ошибок, которые я видел, - это попытка написать собственный язык правил ad-hoc и использовать это для управления условной логикой через базу данных. По крайней мере, используйте язык, который уже был проверен (Python, javscript и т.д.), И вставляйте туда.
Даже если правила достаточно сложны, я лично предпочитаю использовать электронные таблицы Excel. Мы используем это для автоматизации (для обработки переменной логики на основе даты вступления в силу и т.д.), И мы также составляем довольно сложную логику рейтинга страхования для скриптов Perl, взаимодействующих через веб-службу, используя этот продукт: http://decisionresearch.com/products/rating.html.
Контраст сохраняет логику в базе данных по сравнению, скажем, с электронной таблицей Excel:
Теперь, конечно, как вы можете себе представить, движок Excel, управляемый веб-сервисами, не подходит для каждой ситуации. И это не единственное возможное решение здесь.
То, что я получаю, - это то, что вы делаете правильный компромисс с точки зрения удобства использования/выразительности/тестируемости/производительности. Где я работаю, быть прав и быть продуктивным, важнее, чем быть быстрым в исполнении, поэтому мы идем с помощью службы Excel/web.
И чтобы расширить комментарий slavik262, , что вы действительно хотите достичь с помощью движков правил, в конечном счете, это абстракция и обобщение, чтобы свести к минимуму движущиеся части и повысить надежность, тестируемость и понятность. Правила базы данных двигатель, по моему опыту, является субоптимальным для сравнения, часто даже для простого создания, скажем, правил на основе Java. Пока они изолированы и организованы должным образом и скрываются за обобщенным и последовательным интерфейсом, тогда они работают отлично.
В моей компании это зависит от масштаба правил и того, как часто они меняются относительно того, с чем мы живем. Рейтинговое страхование - Excel, без вопросов. Некоторая государственная логика? Совпадающие файлы правил Java достаточно просто.
Если вам не нужно выполнять поиск на основе компонентов правил, вы можете сохранить это правило в двух полях базы данных. Условие, при котором оператор выполняется в одном, и оператор, который выполняется в другом.
id, name, description, condition, statement
Ваши правила могут храниться в JSON или в каком-то подобном формате.
Мне нужно определить некоторую терминологию, которую я буду использовать. Есть атомные термины, системные значения по сравнению со значениями, введенными пользователем, которые оценивают true/false и сложные термины, термины объединяются с использованием логических операторов.
В атомном термине var обозначает значение, которое система предоставит (например, количество посетителей или количество уникальных посетителей). Сравнение определяют, как var оценивается с значением. Значение - это число или строка, которые пользователь производит. Когда var и value являются обоими числами, сравнения могут быть "<", "< =", "=", " > =" или " > ". Когда переменная var и значение являются целыми, сравнения могут быть "равно", "начинается с", "заканчивается" или "содержит". Атомные термины могут храниться следующим образом:
{ var: varName, comp: comparison, value: numberOrString }
Вы можете хранить сложные термины, состоящие из союзов, дизъюнкций и отрицаний (и/или/нет), используя следующие форматы.
// Conjunction
{ op: "and", terms: [ term, ..., term ] }
// Disjunction
{ op: "or", terms: [ term, ..., term ] }
// Negation
{ op: "not", term: term }
Затем вы можете создавать утверждения, которые оценивают true/false с помощью этих методов. Пример следующий:
{ op: "and", terms: [
{op "or", terms: [
{ field: "numVisitors", comp: ">", value: 1000 },
{ field: "numUniqueVisitors", comp: ">=" 100 }
]},
{ op: "not", term: {
{ field: "numVisitors", comp: "<", value: 500 }
}}
]}
Приведенный выше пример равен true, когда число посетителей превышает 1000, или количество уникальных посетителей больше или равно 100, а количество посетителей - не менее 500.
Затем вы можете выполнить то, что вы называете "оператором", когда правило оценивается как true.
Я предполагаю, что цель правил - называть вычисленные поля из существующей таблицы базы данных (или таблиц). В противном случае, для простой отчетности, вы можете отправить данные в Excel и позволить пользователям использовать функции Excel и сводные таблицы для своих целей.
Ключевой вопрос заключается в том, как вы собираетесь превращать правила в действие. Если целью является только сохранение бизнес-правил, поэтому вы можете создать отчет о бизнес-правилах, то достаточно простой структуры данных в SQL.
Однако, если вы хотите превратить правила в код, вам нужно подумать о том, где будет работать код. Когда данные хранятся в SQL, у вас есть несколько вариантов:
У меня есть предвзятость к первому из них. Основная причина в том, что он ограничивает инструменты одним: SQL.
Я не уверен, что делают ваши правила; ключ - это то, что делает компонент "statement". Позвольте мне предположить, что это константа или выражение для данных, которые можно вычислить. В этом случае ваши правила начинают сильно напоминать регистр. Одно из предостережений заключается в том, что для утверждения может потребоваться просмотр более одной строки в вашей таблице данных (для обработки изменений с течением времени).
Моя рекомендация - хранить эти правила в базе данных. Это хранилище позволит вам построить запрос из последовательности бизнес-правил, используя SQL-кодирование. Mysql позволяет динамический SQL (в настоящее время). Не зная немного больше о базовой таблице и правилах, трудно дать больше информации.
Я могу сказать, что я разработал гораздо более сложную систему, используемую для сценарного анализа. Сами сценарии были сохранены в электронных таблицах, в серии таблиц, констант и т.д. - как и ваши бизнес-правила. Система работала с использованием SQL (и некоторого Excel), чтобы преобразовать представление таблицы в сценарий в (гигантский) запрос. Затем он может запустить запрос для создания связанных отчетов. Эта система обладает гибкостью, эффективностью и мощью.
Один простой способ сделать это - использовать OODBMS. Там методы инкапсулируются слотами в объекты, и их можно даже выполнить в базе данных (например, триггеры).
Теперь, если вы настаиваете на базе данных SQL, вы можете использовать динамический язык программирования и иметь таблицу для хранения кода, возможно, связанного с другими таблицами или строками.
Несколько лет назад я увидел тендер на налоговую систему правительства Алжира, в котором они планировали хранить бизнес-правила (налоговые правила), как код Visual Basic в РСУБД.
Вы можете выбрать любой язык, для которого вы можете легко встроить интерпретатор в свое приложение (Common Lisp http://ecls.sourceforge.net; или http://common-lisp.net/project/armedbear/, если вы пишете приложение на Java), Lua, Javascript, Scheme и т.д.
Это будет способствовать использованию Common Lisp или Scheme, поскольку с помощью этих языков вы можете легко написать DSL для бизнес-правил.
Приведенный пример может быть записан как символическое выражение, например:
(rule :name "RuleName"
:description "Some description"
:body (if (and (< (change-in total-visitor) (percent 10))
(> (change-in unique-visitors) (percent 2)))
(do-something)))
в Lisp такое символическое выражение может быть напечатано с помощью PRINT или PRINT-TO-STRING, так что вы можете вставить это выражение в базу данных SQL:
insert into rules (id,expression) values (42,"(rule :name \"RuleName\"
:description \"Some description\"
:body (if (and (< (change-in total-visitor) (percent 10))
(> (change-in unique-visitors) (percent 2)))
(do-something)))");
И вы можете вернуть его из SQL, прочитать его как символическое выражение с помощью операторов Lisp READ или READ-FROM-STRING, а затем с помощью правильного DSL вы можете оценить его с помощью Lisp Оператор EVAL:
;; with the right DSL written:
(eval (read-from-string (sql-select (expression) :where (= id 42))))
Единственное возможное преимущество использования хранимых процедур - это возможность доступа к базе данных из приложений, использующих разные технологии, такие как Python и Java.
Я полагаю, что у вас уже есть существующие правила и требования бизнес-логики?.. Это самый важный фактор для разработки вашей схемы, выбора лучших инструментов для разработки клиентов и разработки ваших клиентских программ и процедур. Я сделал это для своего приложения для управления лотом. Функциональность приложения полностью управляется таблицами. Он имеет контрольные таблицы, в которых администратор может изменять действительные параметры, чтобы изменить способ работы системы. В сочетании со способами структурированного программирования это минимизирует количество модификаций кода программирования. Банковские приложения также являются хорошим примером, который имеет сложные бизнес-правила.