一部のレコードをアプリケーションに格納し、一部をデータベースに格納しますか？

Question

データベース内のエントリではなくアプリケーションコードにハードコードされたレコードを格納し、レコードを表示するときに共通の結果セットをマージできるように見えるアプリケーションがあります。このアプローチに落とし穴がありますか？

まず、アプリケーション開発者が望むとき以外は、レコードが決して編集/削除されないように強制するのが簡単なようです。第2に、サードパーティ製のモジュールをインストールするなどのシナリオでは、データベースに挿入を実行するのではなく、構成からレコードを読み取ることができます（関連する保守上の問題もあります）。

いくつかの一般的な例：

1. データベース内のすべてのレコード
2. アプリケーション内のいくつかのレコードが、一部のレコード：

            In the application  In the database 
   ----------------------------------- ------------------  ---------------------- 
   customers        (none)     all customers 
   HTML templates       default templates   user-defined templates 
   'control panel' interface languages default language   additional languages 
   Online shop payment processors   all payment processors (none) 
   

   だから、私は私がシナリオに応じて3つのオプションを持っていると思いますデータベース内

3. アプリケーション内のすべてのレコード

そして、それを実装するには2つの方法があるようです：

1. データベース内のすべてのレコード：
   • 列が「編集可能」または「ロック」
   • 負のIDとしてフラグを立てることができができロックされた値を表し、正のIDが表すことができ、編集可能な...
2. 一部R
3. 奇数IDがロックされて表し、さらにはIDが編集可能表しますアプリケーション内に生きているecons（変数、配列またはオブジェクト...）

このシナリオを処理する標準的な方法はありますか？本当に明白な解決策がいくつかありますか？

答えが変わったら、私はMySQLとPHPを使っています！

Answer 1

一般に、ワークフローにハードコードされたものを含める場合は、データベースクエリを実行するときはいつでも、参加する必要はありません。ハードコーディングされたデータだけでなく、データベースから取得したデータに対するアクションも簡単です。これは、オブジェクトがアプリケーションに入った後にオブジェクトに形成される情報について話している場合に特に当てはまります。たとえば、アプリケーションにdevユーザーが常駐するようにしたい場合には、これは便利です。このユーザーをアプリケーションにハードコードすることができます。ユーザーにログインするときなど、データベースを照会するときはいつでも、データベースを照会する前に、ハードコードされたユーザーの値をチェックします。例えば

：

// You would place this on the login page 
$DevUser = new User(info); 
$_SESSION['DevUser'] = $DevUser; 

// This would go in the user authentication logic 
if($_SESSION['DevUser']->GetValue(Username) == $GivenUName && $_SESSION['DevUser']->GetValue(PassHash) == $GivenPassHash) 
{ 
    // log in user 
} 
else 
{ 
    // query for user that matches given username and password hash 
} 

これが起こって特別なまたはトリッキーなデータベースのものがあるように必要はありません方法を示しています。データベース駆動型ワークフローに含めるハードコーディング変数は、それを考えすぎないと非常に簡単です。

ハードコードされた変数/オブジェクトがたくさんある場合や、両方の情報セットで大きな論理ブロックを実行したい場合があります。この場合、ハードコードされた情報を保持する配列を持つことが有益ですし、ロジックを実行する前に照会された情報をその配列に追加するだけで済みます。

ペイメントプロセッサの場合は、PayPalやクレジットカードなどのさまざまなサービスを使用してオンラインで支払いを行っているとします。これは、支払い方法ごとに別々の機能を持つ支払いクラスとして最も理にかなっています。そうすれば、クライアントが選択した方法を呼び出すことができます。私はあなたがこれを処理したいと思う他の方法を考えることができません。あなたの顧客が利用可能な支払いオプションについて話している場合は、支払いページにハードコードされたものになります。

うまくいけば、これが役に立ちます。覚えておいて、必要以上に複雑にしないでください。

Answer 2

"アプリケーション内"とは、これらのレコードがアプリケーションにアクセス可能なファイルシステムに存在することを意味しますか？

すべては、作成しているアプリによって異なります。特にコードの複雑さとパフォーマンスに関しては、考慮すべき点がいくつかあります。具体的な提案をするためのプロジェクトに関する十分な情報はありませんが、次の点に注意してください。

すべてのリポジトリを2つ用意することで、コードが複雑になります。つまり、可読性が低下し、奇妙なエラーが発生して追跡が困難になります。ほとんどの場合、おそらく動作する可能性のある最も単純なソリューションに進むのが最善の方法です。大きなPHP/MySQLソフトウェアパッケージを見ると、コード自体に多くのデフォルト値があるにもかかわらず、データはデータベースからほとんど排他的に得られることがわかります。これはおそらく、最も単純な解決策を手放すことができない（つまり、すべてをファイルに保存する）ことができない場合、合理的な方針です。

重度のデータベース関与の大きな欠点は、パフォーマンスです。あなたは間違いなくあなたのアプリでの典型的なコードパスのすべてのデータベース呼び出しを追跡する必要があります。たくさんのクエリに頼っているのであれば、たくさんのキャッシュを使用する必要があります。起こったすべてを追跡し、要求を満たすためにコンピュータが持つことを覚えておいてください。コンピュータの仕事をできるだけ簡単にすることはあなたの仕事です。

テンプレートをデータベースに格納すると、オペコードの再利用とキャッシングが不足するため、パフォーマンスが大きく低下する可能性があります。通常のWebホスティング環境では、PHPファイルを一度コンパイルしてからしばらくバイトコードバージョンを保持しています。これにより、その後の再コンパイルが不要になり、実行速度が大幅に向上します。しかし、PHPテンプレートコードをeval（）ステートメントに書き込むと、このコードは呼び出されるたびにPHPによって再コンパイルする必要があります。

また、このような方法でeval（）を使用していて、ユーザーがテンプレートを編集できるようにする場合は、それらのユーザーが信頼できるものであることを確認する必要があります。他のルートを使用しており、テンプレートエンジンを使用している場合は、セキュリティ上の問題ではなく、より大きなパフォーマンス上の問題が発生する可能性があります。どのような場合でも、可能な限りテンプレート出力をキャッシュすることを検討してください。

ロック機構について：ここでは、各リポジトリ（ファイルとDB）に、どのレコードが他のレコードに制限されていないかを理解させる必要があるため、ここで大きなアーキテクチャ上の問題が発生しているようです。私はこのアプローチを完全に再考することをお勧めしますが、もし必要ならば、別の列を使ってレコードにフラグを立てるよう強く勧めます（IDベースのものは悪夢のように聞こえる）。

標準的な方法は、DBに古典的なDB型のもの（これらはユーザのアカウントやテーブルにうまく収まる他のもの）を保持し、ファイルシステム内のすべてのコードとテンプレートの設定を保持することです。

Answer 3

私はいくつかの固定値をアプリケーションにハードコードしておくと、問題に対処するのに良い方法だと思います。ほとんどの場合、SQLを介してすべての値を取得する必要はないため、データベース・サーバーの負荷を軽減することさえあります。

しかし、ハードコードされた値でデータベースからの値を結合する必要がある場合は、パフォーマンスの問題が発生する場合があります。この場合、すべての値をSQLクエリから取得してコード内で手動で結合するのではなく、データベースサーバーによってすべての値を最適化して処理できるため、データベースにすべての値を格納する方がパフォーマンスが向上する可能性があります。

このケースを処理するには、データベースに値を格納できますが、挿入および更新は保守またはアップグレードルーチンだけで処理する必要があります。データが変更されないように心配している場合は、保守ルーチンを設定して、データベースの値がコードと時々同じであるかどうかを確認できます。この場合、このデータベーステーブルは、ハードコードされた値の「キャッシュ」と同じように機能します。また、固定値とデータベース値を結合する必要がない場合でも、コードからそれらを取得して、不要なSQLクエリを避けることができます（値が同じであることが分かっているため）。