6

私の直感では、開始時間と終了時間は一般的な開始時間と期間よりも優れていると言われていますが、さまざまな方法には具体的な長所と短所があるのではないかと思います。

私が見ているstrttimeとendtimeの利点は、特定の期間中にアクティブなすべてのイベントを呼び出したい場合、その期間の外を見る必要がないことです。

（これは、最初の入力後にあまり変化しない可能性が高く、違いが生じる場合は特定の時間に関連付けられているイベント用です）

4

3 に答える 3

13

私はそれを好みや個人的な選択とは考えていません。コンピューター サイエンスは科学であり、私たちは機械をプログラミングしているのであり、敏感な子供ではありません。

車輪の再発明

業界の巨人によって、リレーショナル データベースのテンポラル データに関する本全体が書かれています。Codd は他界しましたが、彼の同僚で共著者の CJ Date と最近の H Darwen は、 The Third Manifestoでリレーショナル モデルの進歩と改良の作業を続けています。この主題に関する重要な本は、CJ Date、Hugh Darwen、および Nikos A Lorentzos による Temporal Data & the Relational Modelです。

まるでアイスクリームを選ぶかのように、CS 科目に関する意見や個人的な選択を投稿する人がたくさんいます。これは、正式なトレーニングを受けていないため、CS タスクを、その問題に遭遇して解決策を見つけた地球上で唯一の人物であるかのように扱っているためです。基本的に、彼らは他の車輪が存在しないかのように、車輪をゼロから再発明します。技術資料 (ウィキペディアと MS の出版物を除く) を読むことで、多くの時間と労力を節約できます。

モダン ホイールを購入する

テンポラル データは、RM に従って優れたソリューションを実装しようとしている何千人ものデータ モデラーによって取り組まれてきた問題です。それらのいくつかは良いものもあれば、そうでないものもあります。しかし今、私たちは巨人の仕事を手に入れ、真剣に研究し、解決策と処方された治療法を提供しています. 以前と同様に、これらは最終的に SQL 標準に実装されます。PostgreSQL にはすでにいくつかの必要な機能があります (作成者は TTM の一部です)。

したがって、個人的な意見や人気に頼るのではなく、（a）将来性があり、（b）信頼できる（現在存在する何千ものあまり良くない時間データベースとは異なり）これらのソリューションと処方箋を採用できます。あるウェブサイトでの投票。言うまでもなく、コードもはるかに簡単になります。

購入前に調べる

グーグルで検索する場合は、非常に悪い「本」も利用できることに注意してください。これらは、アイスクリーム パーラーで生涯を過ごす博士号によって、MS と Oracle の旗の下で公開されています。彼らは教科書を読んで理解していないため、問題に対する理解が浅く、まったく間違った「解決策」を考え出します。次に、時間データではなく、「ソリューション」に内在する大規模な問題に対して、大規模なソリューションを提供し始めます。特定された唯一の問題に閉じ込められます。トリガーとあらゆる種類の不要なコードの実装に。無料で利用できるものはすべて、支払った価格とまったく同じ価値があります。

時系列データ

そこで、質問の範囲に合わせて、時間の問題を単純化し、教科書のガイダンスを言い換えてみます。正規化と一時的な要件の両方を考慮した単純なルールと、予期していなかった使用法。

  1. 何よりもまず、あらゆる種類のテンポラル列に正しいデータ型を使用します。これは、必要な解像度と範囲に応じて、DATETIME または SMALLDATETIME を意味します。DATE または TIME 部分のみが必要な場合は、それを使用できます。これにより、WHERE 句で直接 SQL 関数を使用して日付と時刻の計算を実行できます。

  2. 次に、列と変数に明確な名前を使用していることを確認してください。

  3. 時系列データには 3 つのタイプがあります。それはすべてを適切に分類することであり、それにより治療 (計画されたものと計画外のもの) が簡単になります (これがあなたの質問が良い質問であり、私が完全な説明を提供する理由です)。利点は、インラインの日付/時刻関数を使用した SQL の単純化です (計画されているテンポラル SQL 関数は必要ありません)。常に保存:

SMALL/DATETIME などのインスタント。更新されたDtm

INTEGER としての間隔。列名で Unit を明確に識別します。IntervalSecまたNumDays

  • 1900 年 1 月 1 日の真夜中からの秒数または月数など、使用されているコンポーネントに関係なく、間隔を DATETIME に格納する必要があると主張する技術者もいます。それは問題ありませんが、より扱いにくい (複雑ではない) コードが必要です初期ストレージ内および抽出されるたびに。

  • 何を選んでも、一貫性を保ちます。

期間または期間。これは、2 つの別個のインスタント間の期間として定義されます。ストレージは、Period が結合か分離かによって異なります。

  • Event 要件のように、連結期間の場合: には 1 つの SMALL/DATETIME を使用します。Period の終了は、次の行の Period の開始から導き出すことができ、保存しないでください。EventDateTimeEndDateTime

  • disjunct Periodsの場合、間にギャップがある場合は、2 x SMALL/DATETIMEs が必要です。RentedFromと_ RentedTo_ それが同じ行にある場合。

  • 行全体の期間または期間は、終了するインスタントを他の行に格納するだけで済みます。ExerciseStartは行の で、ExerciseEndEvent.DateTimeは行のです。X1 EventEvent.DateTimeX9 Event

したがって、Interval として格納された Period または Duration は単に正しくなく、意見の対象ではありません。

データ複製

個別に、正規化されたデータベースで、つまり. whereEndDateTimeが格納されていない場合 (上記のようにばらばらでない限り)、派生可能なデータムを格納すると、存在しなかった場合にUpdate Anomalyが発生します。

  • oneEndDateTimeを使用すると、真実のバージョンが 1 か所に表示されます。重複データの場合と同様に、別の列に 2 番目のバージョンのファクトがあります。

  • 1NFを破る

  • 2 つのファクトは、トランザクション的に一緒に維持 (更新) する必要があり、同期が取れなくなるリスクがあります。

  • 2 つのバージョンの真実があるため、クエリが異なれば結果も異なる可能性があります。

  • 科学を維持することで、すべて簡単に回避できます。戻り値 (単一のクエリの速度がわずかに向上すること) は、データの整合性を破壊する価値はありません。

コメントへの対応

conjunct と disjunct の実際的な違いと、これらの概念がデータベース設計に及ぼす直接的な実際的な影響について、少し詳しく説明していただけますか? (私が違いを理解しているように、私のデータベースの運動と temp-basal は、空白で区切られた別個のイベントであるため、分離しています..一方、常に値があるため、basal 自体は結合します)

そうではありません。あなたのデータベースで（私がこれまでに理解している限り）：

  • すべてのイベントはインスタントであり、期間の結合または分離ではありません

  • 例外は、Exercise と TempBasal で、終了する Instant が保存されるため、ピリオドがあり、ピリオドの間に空白があります。したがって、それらは分離しています。

  • ActiveInsulinPeriod や ActiveCarbPeriod など、より多くの期間を特定したいと思いますが、これまでのところ、原因となるイベント (インスタント) しかありません。

  • 結合したピリオドはないと思います（あるかもしれませんが、特定するのは難しいです。私が言ったことを撤回します（リーディングのときは結合しているように見えましたが、私たちは進歩しました）。

  • 実際の効果で作業できる連結期間の簡単な例については、この時系列の質問を参照してください。テキストとおそらくコードは価値があるかもしれないので、Q/A をリンクしましたが、特に Data Model を見てほしいです。3 つの実装オプションは無視してください。これらは、このコンテキストには関係ありません。

  • そのデータベースのすべての期間はConjunctです。製品は常に何らかのステータスにあります。任意の期間の End-DateTime は、製品の次の行の Start-DateTime です。

于 2011-01-31T06:29:11.867 に答える
4

それは、データで何をしたいかによって完全に異なります。おっしゃる通り、それを保存しておけば終了時間でフィルタリングできます。一方、「1 時間以上続くすべてのイベント」を検索する場合は、期間が最も役立ちます。

もちろん、必要に応じて両方を保存することもできます。

重要なことは、データをどのように使用するかを知っていますか?

編集: 使用しているデータベースに応じて、もう少し肉を追加するために、ビューの使用を検討することをお勧めします: 開始時間と期間のみを (たとえば) 保存しますが、開始時間と期間を公開するビューを用意します。および計算された終了時刻。3 つの列すべてに対してクエリを実行する必要がある場合 (まとめて、または個別に)、データベースがビュー列のインデックス作成をどのようにサポートしているかを確認する必要があります。これには、利便性と明快さの利点がありますが、データの冗長性 (「予備」列を他の 2 つと同期させる必要がある) の欠点はありません。一方で、これはより複雑であり、データベースからのより多くのサポートが必要です。

于 2011-01-28T22:30:05.540 に答える
1

終了 - 開始 = 期間。
End と Duration を使用することもできるので、どの組み合わせにも違いはありません。

あなたが必要とする些細なことを除いてthe column included to filter on it、それを含めてください

  • duration: 実行時間でフィルタリングする必要がある場合
  • 開始 + 終了: 時間枠内で開始および終了するイベントをトラップする必要がある場合
于 2011-01-28T22:40:13.753 に答える