さて、これはまだかなり多くの議論を引き出す分野の1つです。一部の人が言うように[誰？ -Atwood だったと思います とりわけ、リンクは私を逃れます]、すべてを行うことができるアプリケーションはすでに作成されています。それはCと呼ばれます。ビジネスルールが変更されるたびにプログラマーを必要としないことの価値はわかりますが、あなたがやりたいことは「あまりにも一般化された」領域にかなり近いものです。
そのようなシステムを実装する必要がある場合は、ドメインに分割してみてください。あなたはすでに2番目のテーブルでそれの比較的良い仕事をしました。これを、ビジネスルールを複雑にするために使用される個別のドメインに正規化するだけです。 1つまたは複数の制約で構成されるビジネスルールを作成します。各制約には、用語に対して演算子で制限されるプロパティが必要です。用語は、プロパティから関数、複合関数まで何でもかまいませんので、注意が必要な場合があります。ビジネスルールをチェックして、必要なものを確認するのがおそらく最も簡単です。たとえば、プロパティ、ブール値、および「NOW」などのありふれたものから始めます。
したがって、スキーマ自体は、たとえば、rulesで構成されます。 、複数のconstraintsが含まれています （明らかな利点は、これらを任意の[ユーザーグループ/オファー/タイムスパン/その他のドメイン]に関連付けることができることです）。これらは、propertiesで構成されています。 、operatorsの1つと比較します （ほとんどの場合、プログラマー以外のカスタムの説明的な名前を入力できるようにテーブルを参照しますが、ある時点でカスタム関数を入力することもできます）そしてもちろんtermsの1つ 。最後の部分は最も複雑な部分なので、おそらくterm_typesのIDで修飾する必要があります。 したがって、別のプロパティと比較しているか、関数と比較しているかがわかります。 VARCHARだけでもかまいません propertiesにすべてのオプションがあることを考えると、PHPを使用してフィールドを作成します。これはそれほど難しいことではありません。 および/またはfunctions 。
これは非常にオープンエンドのシステムであるため（おそらく、より良い方法があります）、ビジネスルールに高度なダイナミズムが必要であることがわかっていない限り、実行する価値はありません。