8

これは完全に架空の質問です。特定の期間 (1 か月、3 か月、6 か月、1 年など) 存続できるユーザーのメンバーシップを保存する必要があるデータベースがあるとします。

フィールドを持つテーブルMembershipsを持つ方が良いですか (各日付は UNIX タイムスタンプとして保存されます):

user_id INT、start_date INT、end_date INT

または次のように保存します。

user_id INT、start_date INT、length INT

どちらの方法でも、有効なメンバーシップを持つユーザーを照会できます (たとえば)。後者の状況では、クエリが実行されるたびに算術演算を実行する必要がありますが、前者の状況では、(挿入時に) 終了日を 1 回だけ計算する必要があります。そういう意味では前者の方がいいような気もしますが、何かデメリットはありますか？代わりに長さを保存することで回避でき、日付を保存することでは回避できない一般的な問題はありますか?

また、時刻/日付データを格納するときに UNIX タイムスタンプを使用する方法はありますか、それとも DATETIME のようなものが好まれますか? 両方のデータ型 (過度の変換) で問題が発生しましたが、通常は UNIX タイムスタンプに落ち着きます。DATETIME のようなものが好まれる場合、これにより以前の設計上の質問に対する答えがどのように変わりますか?

4

6 に答える 6

2

私は同意しません。開始日と終了日があります-毎回計算を実行する手間を省きます。

于 2012-05-01T13:56:36.753 に答える
2

終了日をインデックス化するかどうかによって異なります。これは、データのクエリ方法によって異なります。

その場合、DBMS が関数ベースのインデックスまたは計算列のインデックスをサポートしていない場合は、end_date直接インデックスを作成できるように物理的なものを用意するしかありません。

それ以外は、あまり違いがわかりません。

ところで、では​​なく、DBMS が提供するネイティブの日付型を使用してくださいint。まず、型の安全性をある程度達成し (したがって、日付が予期される int を読み書きしようとするとエラーが発生します)、不一致の参照整合性をクレートすることを防ぎます (ただし、日付の FK はまれです)。 、タイムゾーンを処理できます（DBMSによって異なります）、DBMSは通常、日付コンポーネントなどを抽出するための機能を提供します...

于 2012-05-01T14:07:29.187 に答える
2

それは、日付に対して実行するクエリの種類によって異なります。クエリに開始/終了時間または日付の範囲による検索が含まれる場合、開始/および日付の場合は、間違いなく最初のオプションを使用します。

統計 (平均会員期間とは何ですか? 1 年以上の会員数は何人ですか?) にもっと興味がある場合は、2 番目のオプションを選択します。

過度の変換について - どの言語でプログラミングしていますか? Java/Ruby は内部で Joda Time を使用し、日付/時刻関連のロジックを大幅に簡素化します。

于 2012-05-01T14:10:14.387 に答える
1

2 つの戦略は機能的に同等です。お気に入りを選択してください。

于 2012-05-01T13:57:12.677 に答える
1

デザインの観点からは、開始日とメンバーシップの長さを設定する方が良いと思います。

終了日は、メンバーシップの開始日 + 期間の導関数です。これが私が考える方法です。

于 2012-05-01T13:53:54.653 に答える