0

これがばかげた質問である場合は申し訳ありませんが、私はリレーショナル データベースに不慣れで、答えを見つけることができないようです (おそらく、他の誰もが既に答えを知っているため)。

わずかに異なるさまざまな形式 (TAI、UTC、GPS など) の時間を含む可能性のあるテスト データを保存しています。入力する前に時刻を任意の一貫した形式に変換することを強制するかどうかはわかりませんが (または、それが最善の方法でしょうか?)、柔軟性を維持できると仮定して、参照テーブル (ルックアップ テーブル) を使用する予定です。 ) のような時間型:

ref_time_types
--------------
id (PK)
desc (UTC, GPS, TAI, etc)

また、実際の時間を格納するテーブルも用意します。

tbl_time
-------------
id (PK)
ref_time_types.id (FK)
seconds
year
.
.
.

私の質問は、私は非常に基本的だと確信しています。これらの間に双方向の関係を確立する必要がありますか、または tbl_time から ref_time_types への一方向の多対 1 関係を確立する必要がありますか? たとえば、すべての UTC 時刻を検索したい理由は思いつきません。それが双方向の関係を構築するかどうかの指針となる原則ですか? 参照テーブルのリレーションシップに関するベスト プラクティスはありますか?

違いがある場合は、python、sqlalchemy、および sqlite を使用しています。

4

1 に答える 1

2

実際にフォーマットを保持する必要がありますか?

  1. そうでない場合は、データベースに保存しないでください。データベースはデータを保存するためのものであり、データが UI でどのように表現されるかは気にする必要はありません。そのため、UI で必要に応じて入力を処理することをお勧めします (それが複数の形式を意味する場合は、それで構いません) が、データベースに保存する前に一貫した形式に変換し、ref_time_types完全に削除します。
  2. はいの場合は、形式も保存しますが、クエリの際に必要な変換が少なくなるため、日付/時刻自体の一貫した表現を引き続き使用します (代わりに、クエリの入力条件を変換するだけで済みます)。目的の形式に一致しないすべての行の）。

また、DBMS でサポートされている日付/時刻型を使用してください。実際にこれらの個々のコンポーネントに対してクエリを実行する (そしてそれらにインデックスを付けたい)場合を除き、さまざまな日付/時刻コンポーネントを個別のフィールドに分割する特別な理由はありません。

これらの間に双方向の関係を確立する必要がありますか、または tbl_time から ref_time_types への一方向の多対 1 関係を確立する必要がありますか?

上で説明したように、最初のケースではリレーションシップは必要ありません (テーブルが 1 つしかないため)。関係は、2 番目のケースでは多対 1 になります。

于 2012-06-05T21:30:49.023 に答える