オブジェクトのタイプが複数ある場合、object.typeはいつ文字列にする必要があり、いつ外部キーにする必要がありますか?
-
05-07-2019 - |
質問
ロマンス、フィクション、またはミステリーの本があるとしましょう。このデータを保存するための2つの現実的なオプションがあります。 1つは、値が「ロマンス」、「フィクション」、または「ミステリー」の文字列である私の本のテーブルにtype列を持たせることです。もう1つは、book_typesテーブルを作成し、そこにタイプを保存することです。その場合、私の本にはbook_typesテーブルを参照するtype_id外部キーがあります。
私の質問は、どれを選ぶのが一番いいですか?ユーザーの状態に関する情報を含むRestful認証Railsプラグインで使用される文字列メソッド-「非アクティブ」、「アクティブ」、「保留中」...
この情報を常にクエリすることを考慮して、ルックアップテーブルメソッドを使用するとパフォーマンスに影響がありますか?
ありがとう!
解決
外部キーアプローチの方がパフォーマンスが向上します。文字列の比較は遅くなります。数値を比較する方がはるかに高速です。
クエリをさらに高速化する場合は、外部キーを参照するために使用している列にインデックスを追加します。主キーとは異なり、外部キーのインデックスは自動的に作成されません。
他のヒント
何かに対して格納される情報がこれ以上ない場合、通常は文字列で問題ありません(ただし、これは非一時的な値であるため、正規形ではありません)。
ただし、これはテーブルの適切な候補のように思えるので、参照テーブルであるimoになるように、カテゴリをさらに活用したい場合があります。
ほとんどの場合、別のテーブルへの外部キーを使用するアプローチが最適です-利点:
-
別の表には、 エントリを検証する拡張可能な方法。テーブル定義にハードコーディングされたチェック制約を入れる 次に、ALTER TABLEを追加して、 新しいタイプ
-
何らかの理由でタイプテキストを変更する必要がある場合(例:「ロマンス」-「>」、「女性のフィクション」、ラメの例)、ルックアップテーブルの軽量更新のみ。
-
エントリがまだないタイプが考えられます。別のテーブルでは、外部結合を使用してSQL結果セットにタイプを含めることができます。
-
インターフェイスの観点から、別のテーブルを使用すると、UIでのハードコーディングを必要としないタイプのドロップダウンリストを簡単に生成できます。
パフォーマンスに関する限り、FKの適切なインデックスを使用すると、RDBMSエンジンは良好に機能します。結合はRDBMSの設計対象です。
fkを使用します。 重複する情報が少ない。
編集: より良いソリューション: MySqlコード:
CREATE TABLE books
(
id int AUTO_INCREMENT not null,
book_type enum('romance', 'fiction', 'mystery') not null,
....
);