フラグ/列挙型を整数ではなく文字列としてデータベースに保存するのはなぜですか？
Drupal 7、Wordpress（かなりかなり古いバージョン））、Pythonベースのカスタムアプリケーションなど、いくつかの有名なCMSのSQLダンプを閲覧してきました。
これらのすべてのダンプには、整数フラグの代わりに文字列フラグを持つデータが含まれていました。たとえば、投稿のステータスは、_1_、_2_、または_3_ではなく、published、closed、またはinheritとして表されていました。 。
私はデータベースの設計に非常に限られた経験があり、単純なSQLを過ぎたことはありませんが、このようなデータには数値/整数のフラグを使用する必要があると常に教えられていました。 tinyintは、たとえばvarchar(9)よりも、データベース内で消費するスペースがはるかに少ないことは明らかです。
だから私は何が欠けていますか？これはデータストレージとデータ冗長性の無駄ではありませんか？これらの列が文字列ではなく整数を使用した場合、参照、検索、およびインデックス作成が少し速くならないでしょうか？
はい、数値の代わりに文字列を保存すると、より多くのスペースを使用できます。知名度の高いプラットフォームがとにかくそれをしている理由は、彼らがそのソリューションの利点はコストよりも大きいと考えているからです。
メリットは何ですか？ enumテーブルを覚えなくても、データベースダンプを簡単に読み取ってその内容を理解できます。また、準公式のGUIでも、取得したレコードを変換するのではなく、単に値自体を使用する場合があります。 （これは、ディスク容量と処理時間のトレードオフの基本的な形式です。）
費用はどうですか？ディスクが非常に大きく安価になったため、データストレージ容量は長い間CMSのボトルネックになりませんでした。一方、プログラマーの時間は通常、より高価になります。したがって、ビジネスの観点からは、ディスク領域と交換する開発努力も何でも良いことです。
はい、yesやtrueなどを保存すると、tinyintよりも多くのスペースが必要になります。これは驚くべきことではありません。また、索引付けが行われるため、データベースの結合の効率が低下します。また、正しい値（yesとy）が混同される可能性があります。
ただし、データベース（特にMySQL）に文字列を保存するのに似ている、効率的なアプローチは数多くあります。
まず、MySQLにはenumタイプ（ docs ）があり、そのように設定すると、ブール値または制限された文字列のセットに非常に似ています。また、有効な値のみが入力されるように強制します。これは、1、2、または3を値として保存するよりもはるかに便利です意味は情報とともに伝えられた。列挙型には、型を追加または削除するためにスキーマの変更が必要であるというペナルティが伴います。
これにより、子テーブルと外部キー（すべてのデータベースに適用可能）が表示されます。はい、キーとして値（1、2または3に戻る）とpublished、closedの値を保存しています。とinheritは別のテーブルに格納されます。ビュー（ docs ）を使用すると、テーブルにキーではなく文字列が含まれているように見せることができます。これには、子テーブルのエントリを追加または削除するためにスキーマを変更する必要がないという利点があります。
正確に格納する方法では、スキーマの実際のDDLを調べて、使用されているメソッドを判別し、選択したトレードオフのヒントを取得する必要があります。