web-dev-qa-db-ja.com

タイムスタンプの部分を別々の列に分割する必要がありますか?

私はPostgreSQLデータベースを構築していて、timestampテーブルを作成しました。ここで、主キーはタイムスタンプ自体です(例:id: Fri Apr 13 2018 15:00:19)。データベースは後でデータウェアハウスに移行され、そこから分析が抽出されます。

この時点で、以下の例のような解析されたメトリックを含むtimestampテーブルに余分な列を追加することが有益かどうか疑問に思っていますまたはIDがの単一のテーブルがあります。

id                       | year | month | day | hour | minutes | seconds
-------------------------------------------------------------------------
Fri Apr 13 2018 15:00:19 | 2018 |   4   | 13  |  15  |    0    |   19


vs


id
-------------------------
Fri Apr 13 2018 15:00:19

私の目標は、データウェアハウスにクエリを実行するときに可能な限り最高のパフォーマンスを達成することです。そのため、タイムスタンプを分割することで仮定すると、リアルタイムで時間メトリックを解凍するのではなく、クエリが高速になります。 :

SELECT * FROM timestamp_table WHERE year = 2018 /* Querying values already parsed */

vs

SELECT * FROM timestamp_table WHERE YEAR(timestamp_id) = 2018 /* Parsing in real-time*/

これに関するいくつかのベストプラクティス入力をいただければ幸いです。

2
GRoutar

タイムスタンプを保持し、パーツの列を追加しないでください。

タイムスタンプの一部を検索する必要がある場合は、いつでもextract式にインデックスを作成できます。

個別の列を使用すると、スペースが無駄になり、望ましくない冗長性が追加されて、想像できない利点が生じます。

6
Laurenz Albe

あなたは時期尚早の最適化に従事しているようです-特定の設計の仮定パフォーマンス特性ではなく、それらをテストするべきではありません。

タイムスタンプ値のコンポーネントを別々の列に格納すると、パフォーマンスの向上はそれほど顕著ではないかもしれませんが、will一貫性のないデータやメンテナンスのオーバーヘッド(またはその両方)のリスクが高まります。

そうは言っても、タイムスタンプのコンポーネントあるかもしれないを保存する正当な理由some個別の列としてのコンポーネント、たとえば:

  • 年、四半期、月などのコンポーネントは、データウェアハウスモデルの有効なディメンションを構成します。
  • データベースの物理設計では、メンテナンスを促進したり、一部の操作のパフォーマンスを向上させるために、時間間隔でデータを分割する必要があります。
5
mustaccio