2

私は、ユーザーが基本的に特定の条件に基づいてアクションを実行する単純な「スクリプト」を作成できるようにする、ウィザードタイプのアプリケーションのようなものに取り組んでいます。それらが構築するスクリプトはデータベースに保存され、変更は一般的であるため、ある種の前方のみのテキスト生成はオプションではありません。私のプログラムは、この内部データベース構造を必要な実際のスクリプト出力に変換するため、スクリプトを変更するたびに出力を再生成します。

この情報を格納できる優れたデータベース構造についてのアドバイスを探しています。現在作業中ですが、少しわかりやすくなるような明らかなものを見逃した場合は、興味があります。任意の提案をいただければ幸いです。

詳細を説明するために、ユーザーがGUIで条件とアクションを選択することで作成できる「スクリプト」のタイプの一般化された例を次に示します。

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>)、より複雑な条件について心配する必要はありません。
  • 各条件には任意の数のテストを含めることができますが、それらは常に同じブール演算子によって結合されます。つまり、条件付きに複数のテストがある場合、それらは常にによって結合されるか、常にによって&&結合され||、混合はありません。
  • 条件文は無限にネストできるため、何らかの階層構造が必要です。
  • 条件文の内部には、定義されているのと同じ順序で実行する必要のあるアクションがいくつでも存在する可能性があります。アクションは関数名として簡単に表すことができ、他の「アクションタイプ」について心配する必要はありません。
4

3 に答える 3

2

「コードのような」ものを保存/操作しなければならないときはいつでも、私は常にXMLルートをたどることになりました。

主な理由は、（aとbと（cまたは（dとe）））のようなものを表現してから計算する方が階層構造の方がはるかに簡単だからです。

あなたの例では、ネストは条件文なので、次のようになります。（非常に大まかな、アイデアを与えるためだけに）

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

SQL2005 +を使用している場合は、HierarchyIdデータ型であり、XML形式の代わりにこれを使用して階層を維持できます。これは、ノードに関連するすべてのデータを取得する場合などに非常に便利です。

注：これは、完全な回答または部分的な回答を意図したものではなく、いくつかの経験を投げかけるだけです。

于 2009-05-28T16:31:36.683 に答える
1

SQLを使用してスクリプトのフラグメントをフェッチまたは検索するための要件については説明していないため、スクリプトを分解する必要はありません。

そのため、スクリプトをデータベースに巧みに保存しようとはしませんでした。代わりに、スクリプト全体をテキストBLOBに格納し、その格納に関してスクリプトを単一のアトミック値として扱います。

スクリプトに対して行う操作はすべてアプリケーションで行われるため、パーサーが必要です。したがって、解析しやすい単純な構文を選択してください。Python、XML、または独自のドメイン固有言語のいずれかをお勧めします。

FWIW、私はデータベースとパーサーの両方で豊富な経験を持っています。これはそれほど難しい作業ではありません。プロジェクトについて説明している限り、これは完全に不要です。

結論：コードはコードであり、データはデータです。

于 2009-05-28T16:33:06.320 に答える
1

各ノードをその親への参照で表し、次に親に対して結合して子を元に戻すことができます。これは、リレーショナルデータベースで階層構造を表す標準的な方法です。

または、各ルールが個別の場合は、テキスト形式またはXML形式で表現し、ルールをBLOBに格納することもできます。これらのルールを多数処理している場合は、Ilogなどの既成のRete-derivativeベースのルールエンジンの使用を検討することをお勧めします。

于 2009-05-28T16:46:38.867 に答える