4

これは、ホテルの部屋に関する情報を格納する2つの（不完全な）データベーステーブルです。保存する情報は同じですが、デザインが異なります。

  1. フロア情報を別の列に保存します。

    | id | floor 
|----|-------
| 1  | 1 
| 2  | 1 
| 3  | 2 
| 4  | 2

  2. フロア情報をIDに保存します。

    | id 
|-----
| 101  
| 102  
| 201  
| 202

表2のようにセマンティックデータをIDに格納することは常にひどい考えですか、それともより表現力豊かなIDを持つことがそれを正当化するのに十分価値がある場合がありますか？

4

6 に答える 6

5

自然キーを使用する場合は、自然キーを使用します。自然キーに名前を付けないでくださいid。

合成キーを使用する場合は、一意である必要があるが他の意味を持たない任意の値として扱います。

于 2013-03-27T02:21:49.323 に答える
3

これは実際にはデータのセマンティクスに関するものではなく、原子性と1NFに違反するかどうかに関するものです。あなたが自分自身に尋ねるべき質問は：

部屋番号は、データ管理の観点からアトミックなデータとして扱う必要がありますか？

つまり、（クライアントコードで部屋番号を全体として扱うかどうかに関係なく）、常にデータベースから部屋番号全体を読み取る（および書き込む）のでしょうか。

  • はいの場合、それを単一の属性にすることができます（そして、それが必要な場合は、キーまたはキーの一部にすることができます）。代理キーも持っているかどうかは別の問題です（以下で簡単に触れます）。
  • いいえの場合（たとえば、フロアを照会する必要があるため、またはフロアをFKとして使用する必要があるため）、それを個別の属性（たとえば、フロア+フロアごとの部屋）に分割する必要があります。そうしないと、違反することになります。 1NF。

注：意図的かどうかはわかりませんが、シナリオ（1）には部屋番号を再構築するのに十分なデータが含まれていないため、シナリオ（2）とは異なるドメインをモデル化します。

ところで、セマンティックデータをキーに格納すること自体は決して悪い習慣ではありません。一部の属性または属性の組み合わせが一意である必要がある場合は、固有の意味があるかどうかに関係なく、それらにキーを作成する必要があります。そのキーを「サロゲート」キーに置き換えることはできません。サロゲートを追加するだけです（想像できるように、長所と短所があります）。

于 2013-03-27T02:02:09.217 に答える
1

テーブルの主キーにセマンティクスを含めることは、確かに悪い考えです。

テーブルの主キーの目的は次のとおりです。

  • ユニークであること、
  • レコードのIDとして使用されます。

このようなセマンティクスを主キーに入れると、次のようになります。

  • すべての部屋に床があり、
  • ホテルは複数ありませんが、
  • 部屋番号に文字を含めることはできません。

これらの仮定は、将来簡単に崩壊します。次に、既存のレコードの主キーを変更する必要があります。これにより、レコードのIDではなくなります。

このようなロジックは、他の場合にも適用できます。たとえば、本の一意の識別子としてバーコードを使用できますが、将来的にはバーコードのない本が作成される可能性があります。

そうは言っても、私はさらに進んで、元のテーブルを、、およびに変更idしroom_numberますfloor。一部のホテルには、迷信のために、などの1301ような部屋番号がありません。1302しかし、それは彼らが13階を持っていないという意味ではありません。

最後にあなたの質問に答えるために-それは必ずしもひどい考えではないかもしれませんが、それが悪い考えではない例を考えることはできません。

于 2013-03-26T22:58:13.110 に答える
1

はい、それはかなりひどい考えです。IDの考え方は、複数列のキーの代わりになる可能性のある行の単一列の一意の識別子であるということです。列を「id」と呼んでいる場合、スキーマを見ている人は誰でも主キーを期待しています。また、それが床の表現であることを知ることで、意味的な価値を失っています。

id列がなく、列を「floor」と呼ぶだけの場合は問題ありません。あなたが心配しているのは、特定のレコードを見つける必要がある場合、それを行うことができるかどうかです。特定のアプリケーションで検索のためにfloor以外の情報が必要ない場合は、列名として「floor」を引き続き使用し、ID列を追加しないでください。ただし、floorやhotel idなどの複合キーがある場合は、他のテーブルで外部キーとして使用できる「ショートカット」単一列キーとしてid列を再度追加することをお勧めします。

于 2013-03-26T23:23:55.517 に答える
0

はい、それは常にひどい考えです：

  • 後で「値」が変更された場合は、IDも変更する必要がありますが、これはさらに悪い考えです。
  • 数値的に隣接するIDを持つ2つの既存の行の間に値を持つデータを挿入する必要がある場合は、新しいIDの余地はありません。
  • IDの目的は、行を一意に識別することです。IDが情報を伝達する場合、その役割が過負荷になっています。これはプログラミングでは決して良い考えではありません。
  • IDに情報を埋め込んだ場合は、それを再度抽出する必要があります。これにより、使用されているすべての場所でコードが取得されます。つまり、労力とメンテナンスが必要になります。
  • 使用する可能性のあるフレームワークは、「最適化」を利用できなくなります。IDのフラグメントではなく、列に値があることを期待します
  • とにかく本当に何を節約していますか？ディスクは安価で、ソフトウェア/ハードウェアは非常に高速であり、節約はごくわずかであり、マイナスを上回ることはありません。

私は過去に自分でやったことがありますが、将来を予測することはできず、ビジネスやデータは予測できない方法で変化するため、常に後悔しています。世界の特定のビューに自分を閉じ込めることは危険です。実際、これが行われるのを見たすべての場合、それは多くの問題につながります。

接吻

于 2013-03-26T23:34:16.673 に答える
0

最上位桁がフロアを識別する番号で部屋を識別することには、まったく問題はありません。私が今まで泊まったすべてのホテルがそうしていると思います。テーブルにそのような部屋番号属性が必要になると確信しています。

あなた自身や他の人の疑問は、あなたが部屋番号を「ID」と呼んでいるためです。部屋番号は識別子です-おそらくそれが本当に重要な唯一の部屋識別子です-しかしそれがあなたの属性が参照しているものであるなら、それを「id」ではなく「roomnumber」と呼んでください。

于 2017-04-25T19:41:21.427 に答える