1

3つの列を含む孤立したテーブル（他のテーブルとの関係はまったくありません）を作成します。

  • Col1-文字列フィールド-VARCHAR（32）-32文字以下の一意のデータが含まれます
  • Col2-文字列フィールド-TEXT-文字のより大きな非一意データが含まれています
  • Col3-数値（ブール）-INT（1）-フラグ付けの場合は0/1

主キーとしてCol1を使用することを考えています。私はいくつかの調査を行い、外部キー/ストレージの問題を回避するために主キーとして無意味なINT列を使用することが道であると人々が主張するのを見ました。

ただし、IMOは孤立したテーブルであるため、問題にはなりません。その上、とにかくCol1にINDEXを配置する必要があります。

ちなみに、このテーブルには1000行を超えるとは思われません。

考えてください。

4

6 に答える 6

2

INT PKを使用して、COL1にインデックスを付けます。そのテーブルに何も結合されないようにすることができれば、インデックスとしてCOL1を使用できると思いますが、それ以外の場合は、インデックスによって、アイテムがテーブルに追加/削除される順序がわかります。また、IsActiveブール値を追加して、ほとんどすべてのテーブルに何も削除せず、DateCreated日時を削除しないようにします。

于 2012-04-17T17:16:17.140 に答える
1

どこから来たのかわかりますが、とにかく最初の列にインデックスを付けるのは理にかなっています。それは私が優れていることに慣れているためかもしれませんが、主キーの最初の列の有用性には、データのデバッグまたはキャプチャ中の読みやすさとともに、それに順序があります。よりランダムに生成された番号を使用する場合でも、数百行を検索して、区別が難しいキーを探します。最後に、intの追加の列を強くお勧めします。それはそれだけの価値があります。

于 2012-04-17T17:14:47.593 に答える
1

データベーステーブルを実行するときは常に、INT列を保持します。数字よりも文字列を比較する方が速いと思います。

したがって、データベースに情報を照会し、そこで文字列を比較する頻度によって異なります。

于 2012-04-17T17:14:51.757 に答える
1

col1が実際の主キーである場合、それを使用しない理由はありません。特にテーブルがそんなに小さいなら。

とにかくその列に一意のインデックスを維持する必要があるため、人工的な主キーを追加することで、挿入および削除操作のオーバーヘッドを追加するだけです（2つのインデックスを維持する必要があるため）。

本当に、本当に多くの他の行（および他のテーブル）からそのPKを参照しているのでない限り、ビジネスルールの自然なプライマリであるものを使用する必要があります。

于 2012-04-17T17:26:19.767 に答える
1

質問が何であるかはまだわかりません。答えから判断して、私はそれを2つのもっともらしい質問に推測しました：

  1. INTEGERの代わりにVARCHARを主キーとして使用しても大丈夫ですか？
    • はい、代わりにVARCHARを使用してもかまいません。
      多くの場合、特にテーブルが2,147,483,647レコードを超えると予想される場合は、これが推奨されます（そうです）。パフォーマンス面では、INTの速度の利点が最小限であったとしても、最大1000のレコードテーブルでは表示されません。指定されたPKは、デフォルトでインデックスが付けられます。1つの問題は、データベースが実行できる自動生成シーケンスが失われることです。
  2. 他の一意のIDフィールドの代わりに、一意のCOL1フィールドを主キーとして使用しても大丈夫ですか？
    • はい、大丈夫です。
      主キーを持つという全体的な概念は、一意のフィールドを確立することです。しかし、あなたが失っているのは、本質的な理解かもしれません。他のユーザーがそのテーブルに参加したい場合、それidが一意のフィールドであることがはるかに理解しやすくなりますが、 col1（一部のvarchar）は一意である場合とそうでない場合があります。
于 2012-04-17T17:58:27.833 に答える
0

あなたの与えられたシナリオでは、それは大丈夫なはずです。スコープが大きくなった場合は、いつでもauto_incrementPK列を導入できます。フィールドにインデックスが付けられ、一意であることを確認してください。

于 2012-04-17T17:12:42.520 に答える