多くのENUMではどちらのアプローチが優れていますか？

Question

これはカスタムソーシャルネットワーク向けです。 |

• プロフィール設定
• SMS： すべてのユーザーは、 "プロファイル設定" ユーザーが変更することができますがあり

  約30の設定、 はので、いくつかのカテゴリがありませ を持っています電子メール通知

• 認証の設定
• セキュリティ設定
• 私はこのような小さなテーブルにその設定を、ドロップすると、私は設定を維持し、いくつかのテーブル（ENUMタイプに）

  を作っアクセス設定

（もちろん、一意のユーザーIDはインデックスに登録されます）

（ユーザーIDはすべてのタブの主キーです）

CREATE TABLE user_profile_settings (...) type=MyISAM; 
CREATE TABLE user_profile_notif (...) type=MyISAM; 
CREATE TABLE user_profile_auth (...) type=MyISAM; 
CREATE TABLE user_profile_security (...) type=MyISAM; 
CREATE TABLE user_profile_access (...) type=MyISAM; 

次に、一度に1つのリクエストがいくつかのテーブルに送られます。 これの利点は次のとおりです。user_profile_settingsからのみ読み込むことができたら、私はそのテーブルからindex'ed idを要求します。

第二のアプローチは、すべてのユーザー設定のユーザのための一つの行を作成するために、このようにしている：

CREATE TABLE all_user_config (/***/) type=MyISAM; 

それは約30 columsを含むが、システム全体を維持するために少し難しくなります。

質問は： どのアプローチが推薦され、10億行に適していますか？

Answer 1

個人的には、ENUMフィールドを1つの大きなテーブルに保存することをお勧めします。したがって、5つではなく1つの巨大インデックスをクエリして更新するだけで済みます。これは幾分古くなったclass diagramが、ダイアグラムが真正であれば、Facebookが行うこと、または少なくともこれまでやっていたことを主張するものです。

推定ユーザー数（Facebookは現在9億人のユーザーが少ない）が深刻な場合は、MySQLなどのリレーショナルデータベースを削除して、SQL値のないソリューション、たとえばキー値店舗Cassandraまたは文書指向MongoDB。それらは、巨大なサイズに拡張し、リレーショナルデータベースよりもスムーズに分散環境に展開する傾向があります。