Можете ли вы использовать таблицы решений в реляционных базах данных

Question

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

Answer 1

Таблица решений - это совокупность условий и действий. Условие может быть достаточно простым, чтобы его можно было представить простой строкой «сопоставить столбец с этим значением». Или условие может быть адски сложным. Аналогичным образом, действие может быть таким же простым, как «переместить это значение в столбец». Или действие может включать в себя несколько частей или этапов или - ну - что угодно.

Функция CASE в предложении SELECT или WHERE является таблицей решений. Это первый пример таблицы решений «в» реляционной базе данных.

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

def decision_table( aRow ):
    result= connection.execute( "SELECT replacement_value FROM transformation WHERE old_value = ?", aRow['somecolumn'] )
    replacement= result.fetchone()
    aRow['anotherColumn']= result['replacement_value']

В каждой строке таблицы решений есть определения типа «соответствовать этому старому» и «переместить это замещающее значение».

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

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

Таблицы решений используются постоянно; они всегда были в реляционных базах данных. Каждая таблица требует строго настраиваемой модели данных. Также требуется уникальная функция условия и процедура действия.

Это не обобщает хорошо. Если вы хотите, вы можете сохранить XML в базе данных и вызвать некоторый механизм правил для интерпретации и выполнения правил BPEL. В этом случае механизм правил выполняет обработку условий и действий.

Если вы хотите, вы можете хранить Python (или Tcl или что-то еще) в базе данных. Шутки в сторону. Вы бы написали условия и действия на Python. Вы получите его из базы данных и запустите фрагмент кода Python.

Много вариантов. Ни один из "академических". Действительно, основное условие - действия выполняются постоянно.

Answer 2

Вопрос о том, стоит ли помещать таблицы решений в базу данных, зависит от ряда других вопросов.

Будут ли рассчитываться ваши условия внутри СУБД или где-либо еще? Если могут быть разработаны данные, используемые для оценки этих условий, и подходящий метод для их оценки внутри СУБД, это, вероятно, хорошая идея. Возможно, ваши действия также происходят внутри вашей базы данных, что сделает ее еще более привлекательной.

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

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

Допустим, у вас есть 6 условий, которые являются двоичными, это означает, что у вас 2 ^ 6 = 64 возможных комбинаций. Тогда у вас может быть один столбец для каждой комбинации и одна строка для каждого действия.

Или у вас может быть 16 условий, что означает, что у вас будет почти неисчислимое количество комбинаций (на самом деле 65536). Что смешное количество столбцов. Лучше иметь столбец для каждого условия и столбец для каждого действия, а также 65536 строк о том, что делать в каждой возможной ситуации. Каждый ряд будет представлять ситуацию и что делать в этой ситуации. Единственный используемый вами тип данных - это bool. Вы также можете упаковать эти выражения в целые числа с битовой маской.

На самом деле, больших таблиц решений лучше избегать. Разделяй и властвуй, и используй больше таблиц - это гораздо лучший способ. Обычно эксперт по предмету устает, если его попросить высказать мнение по слишком большому числу условий.

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

Answer 3

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

Answer 4

Я хотел бы изучить использование базы данных объектов, а не традиционной СУБД (реляционной системы управления базами данных). Объектные базы данных предназначены для быстрой обработки иерархических отношений между объектами, тогда как в СУБД вы должны представлять эти отношения в нескольких строках таблицы или даже в таблицах, чтобы ваши запросы (обходы дерева) были медленными.