私は、ユーザーのすべてについて確かな確かなプロパティがあり、その真実性は確かで、次に私は別のテーブル 'users_derived'を持っていますこの表のデータは、機械学習モデルによって推測されたユーザーのプロパティです。例えば、「年齢」は、彼らが私にそれを供給してからある特定の特性かもしれません、MLモデルがそれを画像から推測したので、「高さ」または「髪の色」は派生した特性かもしれません。主な違いは、 'user'テーブルのすべてのプロパティがユーザー自身によって与えられ、 'user_derived'テーブルのすべてのプロパティがそれに関連付けられた値と確実性を持ち、システムによって推測された。もう1つの違いは、 'users'テーブルのすべてのプロパティがすべてのユーザーに存在することですが、 'users_derived'テーブルのプロパティはそこに存在する場合と存在しない場合があります。時々、私はユーザーのより多くのプロパティでも推測する新しいMLモデルを追加します。SQLスキーマ設計アドバイス
私の質問は、 'users_derived'テーブルのスキーマのやり方です。
userid | prop1 | certainty1 | prop2 | certainty2 | prop3 | etc ...
123 7 0.57 5'8'' 0.82 red
124 12 0.6 NULL NULL black
125 NULL NULL 6'1'' 0.88 blonde
または私はわずかに異なるインデックスと、このようにそれを行うことができます：私はこのようにそれを行うことができ
userid | property | value | certainty
123 1 7 0.57
123 2 5'8'' 0.82
124 1 12 0.60
123 3 red 0.67
124 3 black 0.61
125 2 6'1'' 0.88
etc ....
だからトレードオフは、第二の方法でのように見える、それはのように正規化し、かもしれないではありません照会するのがやや難しくなりますが、事前に気にかけているすべてのプロパティーを知る必要はありません。つまり、スキーマの変更がない新しいプロパティーを追加する場合です。また、我々はまだそのプロパティを持っていないので、我々はそれのための行を持っていないので、NULLスポットがある必要はありません。私は何が欠けていますか？最初の方法の利点は何ですか？ 2番目のスキーマで難しいまたは不可能な最初のスキーマに対して行うことができるクエリはありますか？ 2番目の方法では、索引作成のためのスペースを必要としています。