0

SQLServerに移行するAccessデータベースを継承しました。データベースには、多くのラベル付けまたは分類の列があります。たとえば、注文テーブルにステータス属性があり、サプライヤに評価属性がある場合があります。ほとんどの場合、実際のビジネスロジックはなく、それ自体はエンティティではなく、ユーザーがラベルを付けて検索できるようにするための単なる記述子です。

一方では、これらの記述子は独自のテーブルに配置し、外部キーを使用して参照する必要があると思います。そして、私のアプリケーションコードでは、代理IDに一致する列挙型を使用できます。なんで？簡単に追加できるので、値を簡単に変更でき、スペースを節約できるかもしれません。

Order { OrderId int, CustomerId int, StatusId int}
Status { StatusId int, Name varchar(50)}

一方、これらの属性の多くは変更されることはなく、追加されることもありません。他にもやるべきことがたくさんあるので、そのままにしておくべきだと思います。

Order{OrderId int, CustomerId int, Status varchar(50)}

最初のオプションは、常に実行する必要がある方法を上回っていますか？2番目のオプションは受け入れられますか？そのままにしておくことの唯一の欠点は、テーブルが少し大きくなり、文字列の比較がintの比較ほど速くない可能性があることです。

4

1 に答える 1

0

その[ステータス]列にある値をさらに制御する必要がある場合は、Order.Statusから別のテーブルに個別の値を挿入し、そのテーブルへの外部キー参照を設定することもできます。テーブルを説明するあなたの方法に従うために。。。

Order{OrderId int, CustomerId int, Status varchar(50)}
Status {Name varchar(50)}

ただし、その列には「名前」よりもわかりやすいものを選択します。更新をカスケードするか削除するかは、アプリケーションによって異なります。SQL Serverを使用している場合、SQLGRANTおよびREVOKEステートメントを使用して「ステータス」テーブルを更新できるユーザーを制御できます。（Accessでもそれを行うことができますが、それから離れつつあるようです。）

このテーブルから意味のあるデータを取得するには、3つではなく2つの結合が必要です。その列に50文字が必要かどうかを考えてください。（アクセスのデフォルトは50です。ほとんどの人はこれを変更しません。）

さて、あなたの質問に答えるために、上記の最初のオプションはそれが常に行われるべき方法ではありません。ID番号は常に必要な結合の数を増やしますが、それでも自然キーにUNIQUE制約が必要です。米国の州コード、郵便番号などにID番号を使用することは意味がありません。2番目のオプションは通常私には受け入れられません。私は通常、この回答の冒頭で行ったように、外部キーを使用して別のテーブルを参照します。

于 2013-03-20T00:31:18.680 に答える