記事ディレクトリ
需要の起源
製品の最初のバージョン：ユーザーには、ユーザー名、パスワード、ニックネームなどの3つの属性があり、対応するテーブルデザイン：
user（uid、name、passwd、nick）
第2版では、製品マネージャーが年齢と性別の2つの属性を追加しました。テーブル構造は、
user（uid、name、passwd、nick、age、sex）のようになります。
データ量と同時実行性が比較的大きいと仮定して、どのように変更しますか？
（1）テーブル追加列を変更しますか？実行不可能、ロックテーブルの時間が長い
（2）新しいテーブル+トリガー？データ量が多すぎると、新しいテーブルをインストールできない可能性があります。さらに、トリガーがデータベースのパフォーマンスに与える影響は比較的大きくなります
（3）dbaに任せてください。新しいテーブル、移行データ、整合性チェック、名前の変更？dbaは本当に難しいです
今日は、2列のスケーラビリティ設計に関するいくつかのヒントを共有します。これはすべての人にとって1分しかかかりません（仕事を辞めるのが遅すぎる場合は、1分のシリーズしか書くことができません= _ =）
解決策1：バージョン番号+一般列
上記のユーザーテーブルを例として取り上げます。uidとnameのみにクエリ要件があるとすると、テーブルは
user（uid、name、version、ext）として設計できます。
（1）uidとnameにはクエリ要件があり、別々の列として設計して作成する必要があります。インデックス
（2）バージョンはバージョン番号フィールドであり、
ext（3）のバージョンを説明します。extは、拡張可能な文字列プロトコルキャリアを使用して、クエリ対象の属性を伝達します。
たとえば、起動の開始時のバージョンは0であり、現時点ではpasswdとnickの2つの属性しかない場合、データは次のようになります。
製品マネージャーが属性を拡張する必要がある場合、新しいデータはバージョンを1に変更します。この時点で、年齢と性別の2つのデータが追加され、データは次のようになります。
利点：
（1）プロパティはいつでも動的に拡張できます
（2）古いデータと新しいデータの両方が同時に存在できます
（3）データの移行が便利で、古いバージョンのextを新しいバージョンのextに変更する小さなプログラムを作成し、
不十分なバージョンを変更します：
（1 ）extのフィールドにはインデックスを付けることができません。
（2）extのキー値には冗長性があります。キーを短くすることをお勧めします。
改善点：
（1）extの属性にインデックス要件がある場合は、MongoDBなどのNosqlの方が適している可能性があります。
スキーム2：行を展開して属性を展開する
上記のuserテーブルを例にとると、user
（uid、key、value）
は、最初はname、passwd、nickの3つの属性を持ち、データは次のように設計できます。
将来的には、年齢と性別の2つの属性が拡張され、データは次のようになります。
利点：
（1）プロパティはいつでも動的に拡張できます
（2）古いデータと新しいデータの両方が同時に存在できます
（3）データの移行が便利です。新しいプロパティを追加する小さなプログラムを作成します
（4）すべてのプロパティを照会できます
不十分：
（1）キー値の冗長性が高いため、キーを短くすることをお勧めします。
（2）属性の多いレコードは複数のレコードになり、行数が大幅に増加します。
最終要約
「version + ext」または「key + value」を使用して、製品に新しい列を追加する必要性を満たすことができます。この分を無駄にせず、ただ利益を得るだけです。