DBを使用するのではなく、実際のデータ値をコードにハードコーディングするのはいつですか？

私にとって長年の疑問は、いつデータベーステーブルにデータ（実際の値）を保存し、いつコードに保存するのかということです。

知られていないコンセンサスは、通常そのようなものでした（*）：

単一の変数または単純な構造、またはいくつかの値の配列である場合、コードにデータを直接入れます。

[* コンセンサスはコメントと回答で議論されていますが、基本的には、質問を開始するための何らかの前提を望んでいたので、気軽に挑戦して改善してください]

例：

$number = 44;
$colors = array("blue", "yellow", ... "mauve");

同じタイプの数百行以上のデータがある場合は、データベースを使用します。

しかし、灰色の領域があるようです。それほど明確ではないケースはどうですか？決定を下すために注意を払う必要がある考慮事項と要因は何ですか？

例：
会社が「412T」として表すことができる10〜15種類のモーターフレームを使用しているとします。あなたはそれらの約30を持っています、そして、彼らはめったに変わりません。それらのDBテーブルを作成するか、データベースにハードコーディングできます。この場合、モーターは静的で物理的なものであり、頻繁に変更されることはありません。

それらをコードに保持すると、ソース管理の対象となります。データベースでは、通常、DBの変更は追跡されません。しかし、それらをデータベースに保持すると、コードをデータから解放（分離）できます。

私が使用できる別の（実際の）例は、私の質問です：https : //stackoverflow.com/questions/26169751/how-to-best-get-the-data-out-of-a-lookup-table（現在48オプションデータの行）。

これらの2つのステートメントは、データをハードコーディングするタイミングについてのコンセンサスを実際に表しているとは思いません。

単一の変数、単純な構造、またはいくつかの値の配列の場合、データをコードに直接入れます

同じタイプの数百行以上のデータがある場合は、データベースを使用します

単純な反例（より良いものがあると確信しています）：プログラミング言語の構文テーブルは、しばしばハードコーディングされた複雑で大きな構造です。Perlのソースコードの例をご覧ください。

代わりに、まず質問することに集中します。

• データはどのくらいの頻度で変更されますか？

• 誰がそれを変更する必要があるでしょうか？

「頻度」に対する答えが「アプリの新しいバージョンをデプロイするよりも多い」場合、データをハードコーディングしないでください。

「誰がそれを変更するか」に対する答えが「プログラマー以外のだれでも」である場合、データをハードコーディングしないでください。

小さな店では、コーダーとユーザーの区別がなくなり、「展開」という概念も消えた可能性があります。この場合、あなたはあなた自身のドメインの王様であり、あなたは好きなことをすることができます。

しかし、そのような状況でも、共同作業の必要性が生じる可能性があり、カスタムアプリケーションがプログラマが通常従う慣例に従わない場合、それは困難になる可能性があります。

3番目のオプション、設定ファイルを使用します！

私が取り組んでいるアプリケーション（Javaの場合、私の例はすべてJava + Springを使用しています）では、そのような値は通常、構成ファイルに格納され、アプリケーションの起動時にそれらを必要とするコードに（Springを介して）インジェクトされます。プロパティファイル内：

motorFramesString=412T, 413T, ...

春の設定で：

<bean="motorFrameManager" class="myCompany.MotorFrameManager" >
    <property name="motorFrames" value="${motorFrames}"/>
</bean>

これの利点は、これらのほとんど静的な値を再コンパイルせずに簡単に変更または追加できることです。（リレーショナル）データベースに参照データを入力することを心配する必要はありません（とにかくすべてをデータベースに入れる必要はありません）。

これらの値が参照テーブルの代わりに構成ファイルに入れられる理由については、これらの値を主にコードで、または主にデータベースで使用する予定ですか？これらの値に依存する既存のクエリとビューおよびプロシージャが多数ある場合は、構成ファイルからロードしてすべての可能なクエリにパラメータとして送信するよりも簡単であるため、それらを参照データとしてデータベースに配置するのが最善かもしれませんそれらを参照するビュー/プロシージャ。値の大部分がアプリケーションコードで使用される場合は、おそらく構成ファイルの方が適しています。

リンクするもののようなより複雑な例も、プロパティを使用して、または使用せずに実行できます。

products.propertiesで：

productA.name=Product A 123
productA.hasMotor=true
productA.numFeet=1
productA.hasOutlet=true
productA.needsManual=true

productB.name=Product B 456
productB.hasMotor=false
productB.numFeet=1
productB.hasOutlet=true
productB.needsManual=true

あなたの春の設定ファイルで：

<bean name="productA" class="com.mycompany.Product">
   <property name="name" value="${productA.name}"/>
   <property name="hasMotor" value="${productA.hasMotor}"/>
   <!-- rest omitted for brevity -->
</bean>
<bean name="productB" class="com.mycompany.Product">
   <property name="name" value="${productB.name}"/>
   <property name="hasMotor" value="${productB.hasMotor}"/>
   <!-- rest omitted for brevity -->
</bean>
<!-- configure as many beans as needed -->
<bean="motorFrameManager" class="myCompany.MotorFrameManager" >
    <property name="motorFrames"> <!-- assumes that MotorFrameManager has a property motorFrames which is a List<Product> -->
        <list>
            <ref bean="productA"/>
            <ref bean="productB"/>
        </list>
    </property>
</bean>

これの良い点は、ソースデータがスプレッドシートの場合（リンクした質問のように）、Excelのマクロを使用してプロパティとスプリングスニペットを自動的に生成できることです。

質問の前提はまったく正しくないと思います。分割係数は、変更する必要があるレコードの量ではなく、変更の頻度と変更者です。

周波数

データが揮発性である場合、ソフトウェアのリリースサイクルの外で頻繁に変更されるという意味で、ハードコーディングされた値または構成ファイルの外部で構成できる必要があります。データベースは、特にアプリケーション自体がデータベースを維持できる場合に意味があります。

誰

ときに、顧客が変更データにできるようにする必要があり、それはリリースサイクルのユーザーフレンドリーな方法と外で修正する必要があります。

共通のスレッド

ここでの一般的なスレッドは、ソフトウェアリリース以外でデータを変更する必要がある場合、データベースに保存する必要があるということです。データベースはリリース中にアップグレードされる場合がありますが、データはリセットされたり大幅に変更されたりすることなく存続します。顧客がデータを変更（または機能を構成）できるようにする必要がある場合、それをデータベースに保存して、バカに強いフロントエンドを使用する必要があります。

テスト中

さまざまな構成でソフトウェアを検証する単体テストを必ず作成してください。お客様がオプションのプロンプトをオンにするか、1メートルを12フィートに再定義する場合があります。変更がどれほど合理的であるかに関係なく、ソフトウェアで許可されている場合、変更がどれほど中立であっても、変更が期待どおりに機能することを十分に検証できます。

データの保存場所を決定するのは、変更の頻度でもデータの量でもありません。

プログラムの実行にデータが必要な場合、データはプログラムコードの一部であるため、定数として保存します。他のすべてのデータはデータベースに格納されます。

もちろん、構成ファイル、画像、音声などは通常、ファイルシステムに保存する方が適切です。

ハードコード化されたものが変更されたために電話がかかってアプリケーションを再構築する必要が生じる可能性がわずかでもある場合は、ハードコードしないでください。少なくとも、構成ファイルまたはdbテーブルに保管してください。必ずしもそれを維持するためにUIを提供する必要はありませんが、ダイヤルして設定ファイルを変更するか、テーブルでSQL UPDATEを実行することは、射撃の試合全体を再構築するよりも確実に望ましいです。

実際、この区別はやや灰色の領域ですが、この種の問題に対する私のアプローチは、「本番環境でデータが変更されるか」です。

したがって、あなたが尋ねるべき質問は「どれくらいの頻度で変化するのか？」ではなく、「変化するのか？」です。プロダクション環境で同じコードの反復内で（コードの他の部分に触れることなく）プロパティの値が変化する可能性がある場合は、データベースに格納されます。

また、不足しているのは、「プログラム制御」タイプの情報で、最大バッファーサイズ、順番に声を出したアイテムの数、画面の最大ページサイズは、プログラムまたは構成ファイルに常にハードコーディングされています。

この種のデータをデータベースに保存すると、その場で誰かがそのデータを変更し、システムの動作を完全に変更する可能性が常にあります。

もう1つの問題は、使用するソース管理/変更管理/自動ビルドシステムを通じてデータベースエントリを取得する簡単な方法がないことです。

データベースに保管してはならないことの1つは、データベースにアクセスするために必要な詳細です。
結局、同じデータベースの接続文字列、ユーザー名、およびパスワードを取得するためにデータベースにアクセスする必要がある場合、ちょっとしたキャッチ22があります。

ハードコーディングしますか？うーん、アプリケーションをインストールして出荷する何らかのデータベースを使用している場合に機能する可能性があります。
構成ファイル？より有望ですが、アカウントのセキュリティはどうですか？

もちろん、その構成ファイルにデータベース情報を暗号化された形式で保存できますが、復号化キーをどこかに保存する必要があり、それはほぼ確実にハードコーディングされます。

それとは別に、決して変わらないものがあります。自然定数（G、pi、e、名前を付ける）など、物事は電子メール検証などの特定の正規表現のようなものかもしれません。