"メタデータ"以外は何も含まれていないデータベースがいくつかあります。 たとえば、異なるgrouptypes、contentItemTypes、languagesなどがあります。アイデンティティの使用法はメタデータとの適合性が良いですか
自動番号付けを使用すると、ギャップを作成する可能性があります。 IDは私たちのコード内で使用されているので、番号は非常に重要です。
ここで、これらのテーブルで自動番号付けを使用しない方が良いのではないかと思いますか？
これでコードを記述する前に、まずデータベースに行を作成しました。そして私の意見では、これは事実ではありません。
あなたはどう思いますか？
説明にコードを展開したり他の属性を追加するために使用されるFKテーブルの場合は、IDENTITYは使用しません。アイデンティティはユーザーデータを挿入するのに適しており、メタデータテーブルは通常静的です。コードに更新プログラムをデプロイするときには、驚かれることなく、IDENTITYの値が期待どおりでないようにする必要はありません。
たとえば、「言語」表に新しい値を追加すると、IDは6になると予想されますが、何らかの理由で（開発が同期していない、別のユーザーが次の言語の種類を実装していないなど）次のIDは7とは異なります。次に、言語ID = 6を使用している行を挿入または変換します。存在しないため、すべてが失敗します（メタデータテーブルでは7です）。さらに悪いことに、あなたが思っていた値6がすでにmedadataテーブルに入っていて、同じ6つの値を共有している2つのアイテムが混在していて、新しい7つの値が使用されないため、
必要なコードの数、見たい頻度（CHARはいくつかの値を調べるのはいいですが、メモリに役立ちます）に基づいて適切なデータタイプを選択します。その後、例えば
、あなただけの少数のグループを持っている場合、あなたは多くの場合、生のデータを見てみましょう、CHAR（1）良いことがあります。しかし
GroupTypes table
-----------------
GroupType char(1) --'M'=manufacturing, 'P'=purchasing, 'S'=sales
GroupTypeDescription varchar(100)
、異なる多くが存在する場合値を指定すると、int（tinyint、smallint、int、bigint）の何らかの形がそれを行います：
EmailTypes table
----------------
EmailType smallint --2 bytes, up to 32k different positive values
EmailTypeDescription varchar(100)
プライマリキー（サロゲートキー）として指定したID列を使用して、候補キー（システムの識別子）を標準列に割り当てますが、独自の制約を適用します。これにより、重複したレコードを挿入しないようにすることができます。
意味がありますか？
これらの数字がコードに含まれているために重要である場合は、おそらくIDENTITYは使用しません。
代わりに、INTカラムを使用してプライマリキーにしてください。その場合は、IDを自分で指定する必要があります。その場合は、一意にする必要があります。
コードに数値がハードコードされている場合は、IDフィールドを使用しないでください。誰かがデータベースをひどくスクリプト化したため、データベースにハードコードしているだけでなく、変更が少なくなるでしょう。
私は、レコードをデータベースに挿入するのを簡単にするために、主キーとしてID列を使用しますが、メタデータの型には列を使用し、私はLookUpType（int）を呼び出します。 LookUpId（コード内のint値）または選択リスト、LookUpName（文字列）の値、追加の設定が必要な場合は、余分な列を使用します。私は個人的に2つのエクストラ、階層関係のためのLookUpKey、LookUpNameの略語または代替値のためのLookUpValueを使用します。