Разработка базы данных для условных действий - PullRequest
Новая
       5

Разработка базы данных для условных действий

2 голосов
/ 28 мая 2009

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

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

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

if ($variableA == 100 && $variableB > 25 && $variableC < 10)
{
    performAction();
    performAnotherAction();
    if ($variableC == 0)
    {
        performYetAnotherAction();
    }
    else if ($variableC == 1 || $variableC == 2)
    {
        performEvenMoreActions();
    }
}
else
{
    performDefaultAction();
}

Некоторые заметки о том, что возможно, а что нет, просто для ясности:

  • В условных выражениях «if» может быть любое количество условных выражений «else if», а также необязательное условное выражение «else».
  • каждое условие может иметь любое количество «тестов» ($variableA == 100 и т. Д.), Однако каждый тест можно рассматривать как представленный как (<variable>,<operator>,<test value>), нет необходимости беспокоиться о более сложных условиях.
  • , хотя каждое условие может иметь любое количество тестов, к ним всегда будет присоединяться один и тот же логический оператор. То есть, если в условном выражении несколько тестов, они либо всегда соединяются &&, либо всегда соединяются ||, микширование отсутствует.
  • Условные выражения могут быть вложены бесконечно, поэтому необходима какая-то иерархическая структура.
  • Внутри условных выражений может быть любое количество действий, которые должны выполняться в той же последовательности, в которой они определены. Действия могут быть просто представлены в виде имени функции, нет необходимости беспокоиться о других «типах действий».

Ответы [ 3 ]

2 голосов
/ 28 мая 2009

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

Основная причина в том, что выражение и последующее вычисление чего-то вроде (a и b и (c или (d и e))) намного проще в иерархической структуре.

В вашем примере вложенность - это условные выражения, что-то вроде. (Очень грубо, просто чтобы дать представление) 

<if>
    <expression />
    <true>
        <action />
    </true>
    <false>
        <if>
            <expression />
            <true>
                <action />
            </true>
        </if>
    </false>
</if>

Если вы используете SQL2005 +, у него есть тип данных HierarchyId, вы можете использовать его вместо формата XML для поддержки иерархии, это гораздо более полезно для получения всех данных, связанных с узлом и т. Д.

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

1 голос
/ 28 мая 2009

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

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

1 голос
/ 28 мая 2009

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

Так что я бы не стал умно хранить сценарий в базе данных. Вместо этого просто сохраните весь сценарий в текстовом BLOB-объекте и обработайте сценарий как единое атомарное значение по отношению к его хранилищу.

Любые манипуляции со сценарием будут выполняться в вашем приложении, поэтому вам нужен анализатор. Поэтому выберите простой синтаксис, который легко разобрать. Я предлагаю либо Python, XML, либо ваш собственный предметно-ориентированный язык.

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

Итог: код - это код, а данные - это данные.

...