3

これは、自動インクリメント列を使用した言語テーブルの定義です (DBMS は MySQL です)。

DROP TABLE IF EXISTS languages;
CREATE TABLE IF NOT EXISTS languages (
    language       VARCHAR(16) NOT NULL,
    PRIMARY KEY    (language)
) ENGINE=InnoDB;

これは別のバージョンですが、 UNIQUE 制約が適用されています。

DROP TABLE IF EXISTS languages;
CREATE TABLE IF NOT EXISTS languages (
    language_id    TINYINT     NOT NULL AUTO_INCREMENT,
    language       VARCHAR(16) NOT NULL,
    PRIMARY KEY    (language_id),
    UNIQUE         (language)
) ENGINE=InnoDB;

どちらのバージョンを使用するのが良いかについて、私は2つの考えがあります。一方では、最初の定義は、データベース設計理論によれば正しいものであるように思われます。これは単純に、余分なジャンクが含まれておらず、PRIMARY KEY 制約によって、同じ値を持つ 2 つの行が存在しないことが保証されているためです。たとえば、「英語」という単語が列に 2 回表示されることはありません。もちろん、これは良いことです。しかし、これの問題は、言語列を参照する別のテーブルの外部キー フィールドが、ID 番号ではなく文字列を格納する必要があることです。これは単に、参照テーブルがすべてを列に格納することを意味し、アプリケーションが事前に入力された一意の値を含むドロップダウン コンボボックス リストを提供できる場合、言語テーブルを使用しても意味がないように思われます。しかし、

一方、2 番目のアプローチはより実用的に聞こえます。一意性を確保するために、 UNIQUE 制約を使用できます。参照列に文字列の代わりに整数を使用すると、メモリの消費が少なくなる傾向があり、私の知る限り、文字列よりも検索操作がはるかに高速です。

これをまっすぐにするのを手伝ってください。

4

2 に答える 2

1

ここで同様の質問をしました SQL Dictionary テーブルには IDENTITY 列があるはずです

その場合、コード内の PK 以外でデータを参照することは決してないため、ID 列を持たないことが正しい決定であることがわかりました。つまり、そのテーブルに依存する外部キーはありません。

任意のデータを検索したり、それを外部キーとして参照したりする場合、データベースのサイズを縮小し、外部キーであることがすぐに識別できるため、id 列を使用することを常に主張します。最も基本的なデータベースの知識さえあれば誰にとっても重要です。

于 2013-04-10T19:46:47.950 に答える