2

遭遇したばかりの問題に対する最善の解決策を見つけようとしています。理解せずに物事を行うのは嫌いなので、誰かが助けてくれることを願っています.

ホテル情報を格納するテーブルと、旅程を格納する別のテーブルを含む Access データベースがあります。Itineraries テーブルは、Hotels テーブルのホテルのリストから選択されます。

適切なリレーションシップを作成したいのですが、Itineraries テーブルの Hotels フィールドに接続する Hotels テーブルの Autonumber 主キーを使用してもうまくいきません。(Autonumber ID がホテル名と一致しないためです。)

次のほうがよいですか。

A. 文字列の長さがかなり長くなる場合でも、Hotels テーブルの主キーとしてホテル名を使用しますか?

B. Itineraries テーブルの Hotels フィールドの表示コントロールを、Hotels テーブルの自動採番の主キーをリストするコンボボックスに変更しますが、非表示にします。代わりに、ホテル名の列が表示されます。ここでその解決策を見つけました：http://www.trigonblue.com/accesslookup.htm

ソリューション A は長いテキスト文字列でインデックス作成を遅くする可能性があり、新しいフィールドがテーブルに挿入されるとソリューション B が台無しになると思うので、どちらのソリューションも完璧ではないようです。

ここで間違った答えを選んで、後で問題が発生するのは嫌です。

誰か助けてくれませんか？質問の一部を明確にする必要がある場合はお知らせください。

ありがとう！

4

3 に答える 3

3

名前を主キーとして使用することはほとんどありません。CODEorの形式で一意の ID を使用するID方が、はるかに安全な方法です。名前の使用を避けることで、次のことが可能になります。

  • 識別子から名前を抽象化する
  • 名前を 1 つの場所に保存する
  • 必要に応じて、1 つの場所で名前を変更します
  • 少ないディスク容量とメモリを使用します。
  • より高速なインデックス作成、挿入、削除、結合、並べ替え、およびグループ化を実行します。

場合によっては、既にコードまたは ID を持っている場合や、内部/外部ルールによって制限されている場合もありますが、ほとんどの場合、自動採番された主キーは非常に便利です。それは：

  • 数値なので、効率的に保存されます
  • 数値なので処理が速い
  • ユニークであることを保証
  • 新しいエントリは常にテーブルの最後に挿入され、ページの移動やインデックスの変更に必要な労力は最小限です。
于 2016-09-18T08:06:12.693 に答える
0

現在の高速コンピューターでは、数十または数百のレコードの場合、テキストまたは数値の PK を使用する明らかな違いはありませんが、確かに数千以上のレコードの場合、問題は異なります。数値はCPU 。これは、プロセッサで処理するのが最も簡単なデータ型であるためです。テーブルに何千ものレコードが含まれると思われる場合は、Neumeric を使用し、できれば long 型を使用します。

于 2020-06-16T23:00:07.277 に答える