SQL Serverにタイムゾーンを保存する

Question

私は、異なるタイムゾーンの物理的な場所を使用する世界的なスケジューリングサービスに取り組んでいます。 これらのタイムゾーンは、各場所とともにデータベースに保存されている必要があります。 質問は、どのように保存されているのですか？

現在、カスタムタイムゾーンテーブルを使用しています。これは、カスタム整数IDをMicrosoftタイムゾーンの文字列識別子にマップします。 代わりにIANAタイムゾーン識別子を保存します。 データベースはSQL Serverで、Entity Framework 6を​​使用してC＃でアクセスされます.NodaTimeを使用して時間を処理します。 ソリューションは、これらのすべてのテクノロジでうまく動作する必要があります。

1. は、単にそれぞれの場所と一緒に文字列としてIANA識別子を格納します。
   は、私はそれを行うには、2つの異なる方法を参照してください。
2. すべてのIANA識別子を別のテーブルに格納し、それに外部キーを使用してリンクします。

新しい識別子を簡単に使用できるため、最初の解決策はおそらく最も簡単で、データを緊密に保持します。 しかし、多くのスペースを使用することの欠点があります。

2番目の解決策では、タイムゾーンが必要なときに毎回タイムゾーンテーブルに参加する必要があります。これは、しばしばですが、スペースはほとんど必要ありません。 必要に応じて、新しいタイムゾーン識別子をそのテーブルに追加する必要があります。 また、これらの魔法の整数ID（使用される外部キー）も紹介されています。これは一般に知られている識別子と誤解される可能性があります（IDはデータベースからデータベーステーブル）。

タイムゾーンを保存して文字列識別子としてロードすることができるSQL Server用のカスタムタイムゾーンUDTを作成することが可能な場合でも、私はこれを書いていますが、効率的にユーザー非表示の形式で表示できます。

Answer 1

いずれの方法も有効ですが、一般的な方法はIANAタイムゾーン識別子を文字列として保存することです。彼らは本当に一意の識別子なので、そのように扱うことができます。 "America/Argentina/ComodRivadavia"は現在32文字で最大の文字列であるため、varchar(32)で十分です。しかし、私は通常、将来的に安全であるためにvarchar(50)を使用しています。

ルックアップテーブルに正規化して保存することができる数キロバイトのストレージは、通常、IMHOの影響を受ける価値はありません。しかし、トレードオフのように、両方のオプションを評価してどちらがシナリオに適しているかを確認する必要があります。ルックアップテーブルを使用するには、必ずしもが間違っているとは限りません。