1

データベース内に「メタデータ」のみを含むテーブルがいくつかあります。たとえば、さまざまなグループタイプ、contentItemTypes、言語などがあります。

問題は、自動番号付けを使用すると、ギャップが生じる可能性があることです。IDはコード内で使用されるため、番号は非常に重要です。

これらのテーブル内で自動番号付けを使用しない方がよいのではないかと思います。

これで、コードを記述できるようになる前に、まずデータベースに行を作成しました。そして私の意見では、これは当てはまらないはずです。

皆さんはどう思いますか？

4

5 に答える 5

2

主キー（代理キー）としてID列を使用し、候補キー（システムのID）を標準列として割り当てますが、一意の制約を適用します。このようにして、重複するレコードを挿入しないようにすることができます。

わかる？

于 2009-09-04T07:55:45.363 に答える
1

ええと、それらがコードに含まれるのでそれらの番号があなたにとって重要であるなら、私はおそらくIDENTITYを使用しないでしょう。

代わりに、INT列を使用し、それを主キーにすることを確認してください。その場合は、IDを自分で指定する必要があり、IDは一意である必要があります。

于 2009-09-04T07:57:16.500 に答える
1

コードに番号がハードコーディングされている場合は、IDフィールドを使用しないでください。それらをデータベースにハードコーディングするだけでなく、誰かがデータベースのスクリプトを正しく作成しなかったために変更される可能性が低くなります。

于 2009-09-04T07:59:50.427 に答える
1

データベースにレコードを挿入するために、主キーとしてID列を使用しますが、メタデータのタイプに列を使用し、LookUpType（int）とLookUpId（int値）の列を呼び出します。コード内）または選択リストの値、LookUpName（string）、およびこれらの値がいわば追加の設定を必要とする場合は、追加の列を使用します。私は個人的に、階層関係用のLookUpKeyと、LookUpNameの省略形または代替値用のLookUpValueの2つのエクストラを使用しています。

于 2009-09-04T08:06:48.663 に答える
1

これらがコードを説明に展開するため、または他の属性を含むためだけに使用されるFKテーブルである場合、IDENTITYは使用しません。IDは、ユーザーデータを挿入するのに適しています。通常、メタデータテーブルは静的です。コードに更新をデプロイするとき、驚いたり、予想とは異なるIDENTITY値を使用したりする必要はありません。

たとえば、「Languages」テーブルに新しい値を追加すると、IDは6になると予想されますが、何らかの理由で（開発が同期していない、他の人が次の言語タイプを実装していないなど）、次のIDはgetは7とは異なります。次に、Language 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)
于 2009-09-04T12:20:03.917 に答える