これは、典型的なナローテーブル（属性ベース）とワイドテーブルの説明です。アプローチ＃2の問題は、データをピボットして、ユーザーが操作できる形式にする（ワイドビュー形式に戻す）必要があることです。これは、行の数が増えるにつれて、また属性の数が増えるにつれて、非常にリソースを消費する可能性があります。また、生のテーブルビューでテーブルを見て、何が起こっているのかを確認することも困難です。
弊社では何度もこの議論を重ねてきました。属性タイプのスキーマに非常に適したテーブルがいくつかあります。データをピボットする必要があり、データを表示して意味をなすことができないため、私たちは常にこれに反対することを決定しました（ただし、これは私たちにとって2つの問題の貸し手です-何百万ものデータをピボットしたくないだけですデータの行）。
ところで、私は年齢を数字として保存しません。生年月日があれば保存します。また、「母舌」が何を指しているのかわかりませんが、母が話す言語であれば、これをFKとしてマスター言語テーブルに保存します。言語のつづりが間違っているために、より効率的になり、データの誤りの問題が軽減されます。