Хранение условных логических выражений / правил в базе данных - PullRequest
Новая
       14

Хранение условных логических выражений / правил в базе данных

5 голосов
/ 13 февраля 2009

Как я могу хранить логические выражения с использованием СУБД?

Я отмечаю объекты и хотел бы иметь возможность строить утверждения истинности на основе этих тегов. (Они могут рассматриваться как виртуальные теги.)

Метки
new
for_sale
used
offer

Правило
second_hand_goods = (!new or used) and for_sale
new_offer = new and offer
second_hand_offer = second_hand_goods and offer

  • Правила должны иметь возможность ссылаться как на теги, так и на другие правила.
  • Схемы, которые могут быть легко доступны в спящем режиме, были бы предпочтительнее.
  • Желательно, чтобы можно было извлечь все правило за один выбор / вызов?

Как вы, ребята, храните выражения и бизнес-правила в ваших базах данных?

Заранее спасибо.

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

Ответы [ 5 ]

3 голосов
/ 13 февраля 2009

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

С теоретической точки зрения вы попадаете в Семантическое моделирование данных . Лучшей статьей об этом является документ Hammer и MacLeods Ruritanian Oil Tankers, в котором описывается нотация семантического моделирования данных, образно называемая SDM. SDM использует структурированную нотацию английского типа для разметки правил базы данных того типа, который вы описываете. Если вы хотите обобщить свои возможности и не возражаете написать парсер для SDM, вы можете создать механизм правил, в котором можно настроить такую ​​логику. Этот тип модели также должен быть адаптирован для оптимальной игры с O / R маппером.

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

2 голосов
/ 13 февраля 2009

Управление вложенностью / скобками может стать довольно сложным и подверженным ошибкам. В прошлом я делал это, используя XML для определения логики, так как он очень хорошо справляется с вложением. Используя SQL Server 2005 или выше, вы также можете хранить это в одной таблице.

Ваша логика подержанных товаров может быть сохранена как ... 

<logic type="and">
    <logic type="or">
        <logic type="not">
            <value type="new" />
        </logic>
        <value type="used" />
    </logic>
    <value type="for_sale" />
</logic>

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

0 голосов
/ 10 марта 2009

Я бы использовал одну таблицу 

tags(id,name,type,expression,order)
  • type покажет, является ли тег нормальным или вычисленным.
  • Порядок переупорядочивается при добавлении новых вычисляемых тегов, он определяет порядок расчета для этих тегов ...
  • выражение перед вставкой строки анализируется и проверяется, его также можно создать с помощью графического интерфейса пользователя (что-то вроде того, как Oracle Discoverer делает это).
  • Вы связываете только обычные теги с элементами

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

1,'new',1,'',NULL
2,'for_sale',1,'',NULL
3,'used',1,'',NULL
4,'offer',1,'',NULL
5,'second_hand_goods',2,'(!new or used) and for_sale',1
6,'new_offer',2,'new and offer',1
7,'second_hand_offer',2,'second_hand_goods and offer',2

Элемент может быть помечен только for_sale, вычисление даст: 

second_hand_goods,second_hand_offer

У меня была бы функция, которая выдает список всех тегов для элемента, включая прямые и вычисленные теги: 

for_sale,second_hand_goods,second_hand_offer
0 голосов
/ 13 февраля 2009

Как насчет этого: 

Tables:
 tags( id, name )
 goods ( id, ... )
 goods_tags_mm ( tag_id, good_id )
 rules ( id, name )
 rules_cnf ( id, rule_id )
 rules_cnf_terms ( rules_cnf_id, tag_id )
0 голосов
/ 13 февраля 2009

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

Обновление

Извините, понимаете, я не ответил на ваш вопрос. Вы можете использовать функции, если они есть в вашей БД, которые позволяют передавать параметры и возвращать скалярные значения, или использовать хранимые процедуры. У вас может быть 1 на выражение и более крупная процедура для объединения выражений каким-либо образом.

...