私はこれに対して明確な答えを探しましたが、できませんでした。あらかじめ決められたリストの値だけを受け入れる属性のテーブルを作成する必要があるのはなぜですか？
新しいデータベースを作成するたびに、私は婚姻ステータスと性別のような特定の属性の補助テーブルを作成します。このようにCustomerテーブルでは、結婚状況の列にIDを入力するだけです。 1 - シングル 2 - 3離婚 - 私はいつもこれを行っている
...既婚
など、それはなどしかし、私はそれが良い習慣である知っている、私はそれを学んだ方法ですが、より良いがありますなぜこれを行うのかについての「議論」または厳しい事実？
基本的に、私が働いている人は、新しいデータベースを作成して、別のテーブルにリンクせずにCustomer_Typeをテキストフィールドにする必要があります。なぜこれが悪い習慣であるのか説明したいと思います。
おかげ
あなたが唯一の有効な値を保持するテキスト列を制限することはできませんので、それは悪い習慣です。たとえば、「ジャガイモ」という性別を設定することができます。もう1つの理由は、補助表にリンクするint列よりもテキスト列が多くの領域を占めることです。これは、テーブルのディスク上のスペースが少なくなり、行がよりキャッシュ可能になることを意味します。また、整数列の索引付けは、テキスト値の長さに応じて、テキスト列を索引付けするよりも高速に行うことができます。
しかし、MySQLでは、有効な値のみを持つ列挙型列を作成できます。データの健全性を阻害するほど正確@Swooganによって示さ
は、genderを宣言、VARCHARとしてフィールドのstatusと同様のタイプが悪い習慣です。
また、enumを入力することもできます。列挙型データ型はテキストとしてデータベースに表示されるが、より効率的に格納され、表の作成時に言及された特定の列挙可能な値からの値のみを許容する。 genderの場合は('male', 'female', 'others')です。
gender enum('male', 'female', 'others')
また、すべての可能な男女のための別のテーブルを作成し、あなたの質問に言及したように、外部キーとしてフィールドgender_idを指定することができます。これは理想的なシナリオですが、前者は問題の非正規化された解決策です。そうでなければ、ジェンダーの価値を見つける必要があるたびに参加する必要があります。
しかし、それはフロントエンドで防ぐことができます。あるいは、あなたが他の場所からインポートされた値を扱っているのであれば、実際には問題にはならないでしょう。 –
すべてのデータがフロントエンドから送信されるとは限りません。管理者は、データベース内で直接編集を行うことがあります。それが起これば、それは起こります。データが間違っていないことを保証することは、データベース設計の大きな部分です。 – Swoogan
別のデータベースのデータを使用してデータウェアハウスを作成しています。だから私たちはデータが良いことを100％保証することができます。 –