データベースの最適化：整数や短い文字列による高速検索は何ですか？

Question

私が持っている基本的なデータベース設計/データ型に関する疑問があります。

「experience_required」というフィールドを持つporjectsテーブルがあります。私は、このフィールドは、インターン、ジュニア、シニア、ディレクターのいずれかのオプションから常に入力されることを知っています。このリストは、時間が進展するにつれて少し変わるかもしれませんが、私はその上の項目に劇的な変化を期待していません。

整数または文字列にする必要がありますか？将来、私はこのようなレコードがたくさんあり、expeirence_requiredでそれらを取得する必要があるとき、整数でそれらを持つことに違いはありますか？

Answer 1

まさにInteger over Stringです。

パフォーマンスは向上し、データベースは正規化に近づきます。

最終的に、ExperienceLevelという新しいテーブルを作成し、フィールドIdとTitleを作成する必要があります。既存のテーブルのexperience_requiredフィールドは、別のテーブルの外部キーに変更する必要があります。

これははるかに強力なデザインとなり、利用可能な経験レベルを変更したり、経験レベルの名前を変更する場合にはさらに寛容になります。

正規化hereについて詳しく読むことができます。

Answer 2

整数。文字列は、IMHOはテキストデータ（名前、住所、テキストなど）を格納するためにのみ使用する必要があります。

さらに、整数はこの場合、ソート、ストレージスペース、およびメンテナンスのために優れています。

Answer 3

あなたはこのフィールドの索引付けが好きかもしれません。一度索引されたIntegerと小さな文字列は、パフォーマンスの差があまりない（読みにくい）。

Answer 4

理論では、整数にインデックスを付けるとメモリの消費量が少なくなります。 文字列のように見えるが、整数として格納されるenum（mysql内）を使用することもできます。

Answer 5

問題ではありません。違いはごくわずかです。どのような違いがあるかは整数の選択に賛成ですが、これは短いテキストキーを好む少数のケースの1つで、多くのレポート状況でJOINをルックアップテーブルに戻すためです。

Answer 6

いくつかの水を泥だらけにするために、私はミックスを提案します。 @ GregSansomの考え方（upvoted）から始めるが、整数の代わりにCHAR(1)のデータ型をI、J、S、Dの値で使用する。これにより、tinyintを使用するのと同じパフォーマンスが得られ、覚えやすいニーモニック（データを直接扱う場合）。少し使いますが、 "S"は "シニア"を意味していますが、3は意味を持ちません。特に、あなたが示唆するように、時間の経過と共に余分な値が追加された場合は特にそうです。 （例えば、5のように検定を追加すると、「低いランク=低い値」のパラダイムがウィンドウ外に出ます）

これは、アイテムのリストが非常に短い場合にのみ機能します。あまりにも多くの、またはあまりにも似通ったものを取得して、使用可能なコードを処理するのは難しいです。

もちろん、これらが連続値の場合はどうなりますか？確かにここのように聞こえる。その場合、それらを1,2,3,4にして10,20,30,40としないでください。新しいカテゴリを後で挿入することができます。これにより、 "everyone < 30"（「シニア」未満を意味する）などの範囲を簡単に実装することもできます。

私の主なポイントは、あなたのデータを知っているか、どのように使用されているか、時間の経過と共にどのように変化するか、それに応じて計画し、コード化することです。