Модель данных для булевых выражений

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

можно, например, использовать поля:

• идентификатор
• TypeExpression (и, или и т.д....)
• FirstChildID
• SecondChildID

В этом случае, у Вас есть следующие типы:

1. И, Дети указывают на другое выражение.
2. ИЛИ, Дети указывают на другое выражение.
3. Равный, Дети указывают на другое выражение.
4. Литерал, FirstChild указывает на запись в литеральной таблице.
5. VariableLookup, FirstChild указывает на запись в varable таблице.

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

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

Этот тип выражения, как правило, выражается как дерево (иерархия), которые являются известно раздражающими для запросов в SQL.

Мы предположим, что a и b являются числовыми в настоящий момент и что литералы ('1', '2') отличают от переменных.

Table Nodes
id
type (Variable|Literal)
name (nullable for literal)
value

Table Operators
id
name (=, AND, OR, NOT)
leftNodeId
rightNodeId

Эта структура очень гибка, но запросы ее для получения сложного выражения будут "забавой" (считайте то "оспаривание").

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

Традиционный способ смоделировать булевы функции состоит в том, чтобы использовать Бинарные схемы принятия решений , особенно Уменьшенные Бинарные схемы принятия решений Порядка. Возможно, что можно найти расширение для DBMS, который оказывает хорошую поддержку для понятия.

ОБНОВЛЕНИЕ: Поочередно, если Вы не должны запрашивать на Булевой логике, Вы могли бы пользоваться библиотекой BDD и просто сериализировать BDD в BLOB или эквивалентный. Это бьет использование varchar поле, потому что библиотека BDD гарантировала бы, что данные были допустимы.

Добавление к ответу @Gamechat

я думаю, что это должно быть похожим на это

идентификатор

TypeExpression (и, или и т.д....)

FirstChildID - Это может быть вершиной или указателем на другую строку в той же таблице

SecondChildID - Это может быть вершиной или указателем на другую строку в той же таблице

isFirstChildLeaf

isSecondChildLeaf

Опция 1 состояла бы в том, чтобы использовать вложенную таблицу (дерево с идентификатором / parent_id структура), как предложенный Gamecat. Это относительно дорого, чтобы сделать и требует, чтобы SQL-запросы издания повторяющимся образом создали эквивалент единственного вложенного выражения.

Опция 2 состояла бы в том, чтобы использовать сериализованный объект и сохранить его в varchar столбец. Например, JSON был бы хорошим выбором. Это не чувствительный пробел, может быть создано и проанализировано в огромном количестве языков, и это сохраняет целостность данных.

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

Я бы сохранил выражение в полированной форме, в столбце varchar / text. Выражение в безупречной форме (операнд перед операндом, без скобок) намного проще анализировать с помощью рекурсивной функции (или, конечно, стека).

a = 1 AND (b = 1 OR b = 2)

в полированной форме выглядит следующим образом:

AND = a 1 OR = b 1 = b 2