74

クーポン/割引を格納するテーブルがあり、coupon_code 列を主キーとして使用したいと考えていますVARCHAR。

私の理論的根拠は、各クーポンには一意のコードがあり、実行するコマンドは次のとおりです。SELECT ... FROM ... WHERE coupon_code='..'

結合やインデックス作成は行いません。また、このテーブルに数百を超えるエントリが存在することはありません。

これで問題ないように思えますが、欠けているものや考えていないものがあるかどうかはわかりません。

4

4 に答える 4

20

「すべきではない」というブランケットはひどいアドバイスです。これは、ユースケース、ワークロード、データエントロピー、ハードウェアなどに応じて、多くの状況で完全に合理的です。すべきでないことは、仮定を立てることです。

MySQL のインデックス作成を制限するプレフィックスを指定できることに注意してください。これにより、残りをスキャンする前に結果を絞り込むことができます。ただし、プレフィックスが「いっぱい」になり、一意性が低下するにつれて、これは時間の経過とともに役に立たなくなる可能性があります。

実行するのは非常に簡単です。たとえば、次のようになります。

CREATE TABLE IF NOT EXISTS `foo` (
  `id` varchar(128),
  PRIMARY KEY (`id`(4))
)

また、列の引用符の後にプレフィックス(4)が表示されることにも注意してください。は、.4id

最後に、使用する前に、インデックス プレフィックスのしくみとその制限をお読みください: https://dev.mysql.com/doc/refman/8.0/en/create-index.html

于 2014-04-06T14:41:06.903 に答える
2

これは、特定のユース ケースによって異なります。

テーブルが静的で、値のリストが短い場合 (DB の有効期間中にこれが変更される可能性はわずかです)、次の構成をお勧めします。

CREATE TABLE Foo 
(
    FooCode VARCHAR(16), -- short code or shortcut, but with some meaning.
    Name NVARCHAR(128), -- full name of entity, can be used as fallback in case when your localization for some language doesn't exist
    LocalizationCode AS ('Foo.' + FooCode) -- This could be a code for your localization table... 
)

もちろん、テーブルがまったく静的でない場合は、主キーとしてINTを使用するのが最善の解決策です。

于 2015-05-05T06:47:12.890 に答える