0

他の誰かが作成したアプリケーションに取り組んでいますが、データベースで定義されていないIDをアプリケーション全体で使用しているようです。簡単な例として、Questionというテーブルがあるとします。

Question
------------
Id
Text
TypeId
SubTypeId

現在、SubTypeId列には、データベース内の別のテーブルを参照しないIDのセットが入力されています。コードでは、これらSubTypeIdは構成ファイル内の特定の文字列にマップされます。

以前はこれらのタイプの値を使用していたときに、ルックアップテーブルを作成して適切な値を挿入していましたが、このアプリケーションでは、IDとそれに対応するテキスト値の間に構成ファイルのマッピングがあります。

データベース自体ではなく、構成ファイルでルックアップテーブルを定義するのは悪い習慣ですか？

4

2 に答える 2

1

データベース自体ではなく、構成ファイルでルックアップテーブルを定義するのは悪い習慣ですか？

はいぜったいに。参照の管理と維持、必要な値のフェッチなどをコードに大きく依存します。追加の機能を作成する必要がある状況では、マッピングのコピー貼り付け（またはインポートなど）に依存します。これは問題を引き起こす可能性が高くなります。

これは、DB制約がアクセスしているプログラム/アプリケーションではなくDBにある必要がある理由と似ています。メンテナンスや新しいアプリケーションでは、すべての動作とルールを複製する必要があります。このようにすることには、別の回答でここで述べたのと同様の副作用があります。

ルックアップテーブルを持つ正当な理由：

  1. DBは一般的にこれらの種類の関係を持つことができるので、それらを使用することは明らかです。
  2. クエリは、実際に実行されるクエリのwhere /have句の一部として使用するのではなく、最初にType-およびSubType- TextvsIDのコードで作成する必要があります。
  3. 速度/パフォーマンス-適切なインデックスとテーブル構造を使用すると、これからメリットを得ることができます（そして、それを管理するコードの複雑さを軽減できます）
  4. Type新しいまたはを追加したりSubType、それらを編集/削除したりするためにコードを更新する必要はありません。

それがそのように行われた可能性のある理由、それは正当な理由ではないと私は思います：

  • およびは関連TypeIDしSubTypeIDており、元の設計者は複雑な外部キーを作成する方法を知りませんでした。（しかし、正当な理由ではありません。）
  • もう1つは「翻訳」である可能性がありますが、外部キー関係を使用して処理することもできます。
  • 一部のコードでは、厳密な関係がなくTypeID、SubTypeIDそのロジックがDBではなくコードで処理されている場合があります。この場合も、「フラグ」値または可能であればNULLを使用して管理できます。これらの特定のケースは、DBを正しく設計し、コードにすべての依存関係を置くのではなく、コード内の固有の/奇妙な状況を回避することで処理できます。
  • NoSQL：元の設計者は、そのような外部キーまたはリレーションをNoSQLデータベースで実行できないという印象を受ける可能性があります。
  • そして、明らかな「人」の問題と技術的な課題：元の設計者はデータベースを適切に理解しておらず、適切な知識や支援なしにそのアプリケーションを実行した（または実行させられた）プログラマーであった可能性があります。
  • 前の設計者が外部の請負業者だった場合、彼はより多くのビジネス/お金を得るための手段としてコード保守の複雑さまたは「サポート」句を使用した可能性があります。
于 2013-03-05T04:25:41.750 に答える
0

一般的な経験則として、関連するすべてのデータをDBに保持することは、DBとアプリの間の暗黙の依存関係を取り除き、DBをより「理解しやすく」するため、より良い方法だと思います。SubTypeIDの定義がルックアップテーブルにある場合、人間が読める形式の結果などを返すクエリを作成することが可能になります。

とはいえ、正しい答えはおそらくアプリケーションの詳細に少し依存します。そもそもDBとアプリの間に非常に緊密な結合がある場合（たとえば、DBが他のクライアントによってアクセスされない場合）、特にSubTypeIDのセットが小さく、ほとんど変更されない場合、これはおそらく小さな問題です。

于 2013-03-04T22:17:09.850 に答える