私は、異なるタイム ゾーンの物理的な場所を使用する世界規模のスケジューリング サービスに取り組んでいます。これらのタイム ゾーンは、各場所と共にデータベースに保持する必要があります。問題は、それらをどのように保管するのが最適かということです。
現在、カスタム整数 ID を Microsoft タイム ゾーン文字列識別子にマップするカスタム タイム ゾーン テーブルを使用しています。代わりに IANA タイム ゾーン識別子を保存したいと考えています。私たちのデータベースは SQL Server であり、Entity Framework 6 を使用して C# でアクセスされます。NodaTime を使用して時間を処理します。ソリューションは、これらすべてのテクノロジとうまく連携する必要があります。
それを行うには2つの異なる方法があります。
- IANA 識別子を各場所とともに文字列として保存するだけです。
- すべての IANA 識別子を別のテーブルに保存し、外部キーを使用してリンクします。
最初の解決策は、新しい識別子を簡単に許可し、データを緊密に保持するため、おそらく最も簡単です。ただし、多くのスペースを使用するという欠点があります。
2 番目の解決策では、タイム ゾーンが必要になるたびにタイム ゾーン テーブルに参加する必要がありますが (これはかなり頻繁に行われます)、必要なスペースはほとんどありません。必要に応じて、新しいタイム ゾーン識別子をそのテーブルに追加する必要があります。また、これらの魔法の整数 ID (使用される外部キー) も導入されますが、これは一般的に知られている識別子であると誤解される可能性があります (現在、ID がデータベースから移動し、データベースの代わりに使用されるコード内辞書に移動したという問題があります)。テーブル）。
これを書いているとき、SQL Server 用のカスタム タイム ゾーン UDT を作成することさえ可能かどうか疑問に思っています。タイム ゾーンを文字列識別子として保存およびロードできますが、より効率的にユーザーに格納できます。・隠しフォーマット。