web-dev-qa-db-ja.com

ビジネスルールの保存に構成ファイルまたはデータベースを使用する必要がありますか？

私は最近読んでいます The Pragmatic Programmer これは次のように述べています：

詳細は、特に頻繁に変更される場合、元のコードを台無しにしてしまいます。ビジネスロジック、法律、または当日の経営陣の個人的な好みの変化に対応するためにコードを変更する必要があるたびに、新しいバグを導入するというシステムを破壊するリスクを負っています。

ハント、アンドリュー。トーマス、デビッド（1999-10-20）。実用的なプログラマー：ジャーニーマンからマスターへ（Kindle Locations 2651-2653）。ピアソン教育（米国）。キンドル版。

現在、一連の値からのみ取得できるプロパティを持ついくつかのモデルを持つWebアプリをプログラミングしています。 （Webアプリのデータは機密情報としての実際の例ではありません）：

ライト->タイプ=球/立方体/円柱

ライトのタイプは上記の3つの値のみですが、TPPによると、値を変更して構成ファイルに配置できるかのように、常にコーディングする必要があります。アプリ全体でいくつかの問題が発生しているため、私の質問は次のとおりです。

次のような値を格納する必要があります：

  • 設定ファイル：
    'light-types' => array(sphere, cube, cylinder),
    'other-type' => value,
    'etc' => etc-value

  • 各構成アイテムに1行のデータベース内の単一のテーブル

  • 各構成アイテムのテーブルを含むデータベース（例：テーブル：light_types;列：id、name）

  • 他の方法？

提供された支援/専門知識に感謝します。

designdatabaseconfiguration
42
foiseworth

同じ問題が、私が取り組んでいるほとんどのプロジェクトで発生します。通常、私はこれを行います：

  1. 可能な値のセットがすぐに変更される可能性が低い場合は、コードでクラス/インターフェイス定数または列挙型を使用し、データベースで列挙可能なフィールドを使用します。例：ブログエントリの公開状況：「未公開」、「モデレート中」、「公開済み」など.
  2. 値はおそらく変更されますが、変更はプログラムロジック（設定ファイル）には影響しません。例：「どのようにして当社のWebサイトを見つけましたか？」のリストオンライン購入フォームのドロップダウンリストのオプション。
  3. 値は頻繁に変更される可能性が高いか、開発者以外が編集することを目的としていますが、これらの変更はロジックに影響を与えません-データベース、または少なくともユーザーフレンドリーな編集用インターフェイスを備えたKey-Valueストレージ。
  4. 値を変更するとロジックに影響します。おそらくシステムの再設計（多くの場合はtrue）が必要か、ビジネスルールエンジンが必要です。これまでに見た中で最も困難なケースは、同僚が取り組んだ心理テストのコンストラクタでした。各タイプのテストには、独自のスコアリングシステムがあり、単純な加算から、正の値と負の値の複数の特性スケール、または人間による解答の評価までさまざまです。このプロジェクトについての議論の後、スクリプトエンジンとして Lua を使用することになりました。これは、非開発者が新しいテストを作成する機能と完全に競合します（Luaは比較的単純な言語ですが、非プログラマーがそれを学ぶことを期待してください）。

TPPからの引用について。 pristineコードには当てはまると思いますが、実際には、単純な（ KISS原則 ）から始めて、後で機能を追加する方が良いでしょう。本当に必要な場合（ [〜＃〜] yagni [〜＃〜] ）。

45
scriptin

データがデータベースにある場合、同じDBに「light_types」のテーブルを置くことをお勧めします。これにより、外部キーを使用してlight-> typeがこれらの値の1つだけになるという制約を適用できます。そのため、コードがめちゃくちゃになっても、DB内のデータは常に有効です。

データがDBに格納されない場合、一連の列挙型のためだけにデータを作成しても、あまり効果はありません。値のハードコーディングを本当に避けたい場合は、設定ファイルをお勧めします。

（ただし、ハードコーディングを回避しすぎないように警告します。重要なシステムでは、作成者がそれを理解しているかどうかに関係なく、ビジネスルールと要件についての仮定があります。仮定と絶対にすべてをソフトコード化すると、基本的には「ルールエンジン」、つまりシステム内のシステムやメタ言語のようなものになり、メタ言語にはたくさんのものがありますルールを実装します。作業を保存したり、柔軟性を獲得したりせず、別の言語を作成したり、学習したりする必要があるだけです。

ここで、既存のルールエンジンを見つけて使用したい場合は、thatを使用すると、（enumを格納する場所の質問に答えるだけで）少し作業が軽減される可能性があります。しかし、独自のビルドを行うと、ワークロードが2倍になり、まともなルールエンジンの作成方法を本当に知らない人によって構築された中途半端なシステムが必然的に作成されます。）

7
cHao

一般に、データにはデータベースを使用し、構成には構成ファイルを使用する必要があります。 （名前が示すように:)）。データベースに構成を保持することは、懸念事項の分離が悪いため、正当化するための適切なユースケースがある場合にのみ実行する必要があります。

使用する構成を決定する際には、バランスを取る必要があります。構成ファイルは、アプリケーションの一部と同じくらいコードとして扱う必要があります。できるだけ簡潔にしてください。魔法の文字列でいっぱいの巨大なxmlファイルになってしまう構成の膨張にアプリケーションが苦しむのは非常に簡単です。

あなたが説明する場合には、どのcssファイルを使用するかを定義するための設定要素を持つことが合理的でしょう。 （要件が変更された場合は、変更することができます）。構成ファイルで各要素のスタイルを構成するのはやり過ぎです

0
Tom Squires