特定の場所の特定の時間の天気予報を表すビジネス エンティティがあります。気温、気圧、風速など、特定の場所と時間に予測されるさまざまな種類の気象パラメーターがあります。すべてのパラメーターが利用可能であるとは限りません。新しいパラメーターを追加するために柔軟に対応したいと考えています。
これらのニーズに合ったテーブルを設計したい場合は、次のアプローチを使用できます (エンティティごとに 1 行)。
myforecasttable:
- location_id PRIMARY
- timestamp PRIMARY
- airtemperature
- airpressure
- windspeed
- etc.
または、次のアプローチ (エンティティごとに複数行) を使用することもできます。
myforecasttable:
- location_id PRIMARY
- timestamp PRIMARY
- parameter_type PRIMARY
- value
...ここで、天候パラメータの具体的なタイプ (気温、気圧など) を表すorparameter_type
になります。enum
string
最初のアプローチではNULL
、異なる列の値を取得しますが、クエリはより簡単になります。2 番目のアプローチでは、新しい気象パラメーターを追加するのははるかに簡単になりますが、クエリはおそらく難しくなります。
これらのデザインの長所と短所はありますか? ユースケースに最適なデータベース設計を選択するにはどうすればよいですか?