Meilleur moyen de stocker des données de date/heure dans SQL Server 2008 R2 et SQL Server Compact 4

Question

Nous développons une application en C# 4 qui utilise SQL Server 2008 R2 comme backend. SQL Server Compact 4 est également utilisé pour les clients déconnectés dans quelques rares scénarios. Nous nous demandons quelle est la meilleure façon de stocker des données de date et d'heure dans ces bases de données afin que.. :

1. Les données contenant des décalages horaires différents (provenant de fuseaux horaires différents) peuvent coexister sans problème. Cela signifie qu'elles peuvent être triées et comparées.
2. Les données de SQL Server 2008 R2 et de SQL Server Compact 4 peuvent être transférées dans les deux sens de manière transparente ; il s'agit d'une exigence secondaire qui ne doit pas compromettre la conception choisie.

Notre principale préoccupation est de préserver l'heure locale pour chaque événement enregistré, mais sans perdre la possibilité de comparer et de trier les événements qui ont été générés à partir de fuseaux horaires différents et qui ont donc des décalages horaires différents.

Nous avons examiné le datetimeoffset puisqu'il stocke le décalage horaire et qu'il s'adapte parfaitement à l'algorithme de .NET DateTimeOffset . Cependant, elle n'est pas prise en charge dans SQL Server Compact 4. Une alternative serait de supprimer les informations de décalage de la base de données et d'utiliser une simple fonction datetime de sorte que chaque donnée de la base de données est normalisée et que les problèmes liés à Compact sont moins nombreux. Cependant, cela introduit le problème que l'information de décalage devrait être reconstruite d'une manière ou d'une autre lors de la récupération avant que l'utilisateur ne voie les données.

Ma question est donc la suivante : existe-t-il des bonnes pratiques ou des directives sur la manière de stocker des valeurs de date/heure dans SQL Server, en tenant compte du fait que nous devrons gérer différents fuseaux horaires, et en rendant l'interopérabilité entre 2008 R2 et Compact 4 aussi facile que possible ?

Merci.

Answer 1

Il semble que les points pertinents soient :

• Vos données entrantes correspondent bien à DateTimeOffset
• Vous ne vous préoccupez que de l'offset à ce moment précis, donc vous n'avez pas besoin de l'option réel le fuseau horaire. (Un décalage n'est pas un fuseau horaire).
• Vous do Vous ne pouvez pas simplement tout normaliser en UTC et ignorer complètement le décalage.
• Vous voulez faire une requête sur le local temps.

On dirait bien que DateTimeOffset est fondamentalement le type le plus approprié dans ce cas. Vous devez cependant vous assurer que tous les membres de l'équipe comprennent bien ce que cela signifie - le décalage est le décalage lorsque les données ont été reçues à l'origine. Si vous souhaitez afficher cet instant dans le temps dans un fichier différents vous devez effectivement revenir à l'UTC et trouver quel serait le décalage dans ce fuseau horaire d'affichage. Il est facile de s'embrouiller avec ce genre de choses :)

Si vous devez maintenir les données dans SqlServerCE avec une fidélité totale, vous aurez probablement besoin d'un champ DateTime et ensuite d'un champ séparé pour le décalage (par exemple en minutes, ou en tant que TimeSpan si SqlServerCE le supporte).

Answer 2

Vous avez probablement raison d'utiliser DateTimeOffset sur le serveur. Vous pouvez également lire ma réponse sur DateTime vs DateTimeOffset .

Sur le client, où vous utilisez SQLCE, stockez un fichier DateTime avec des valeurs UTC. Lorsque vous envoyez les données au serveur, vous pouvez utiliser le fuseau horaire local du client pour déterminer la date et l'heure de l'événement. DateTimeOffset à laquelle correspond la valeur UTC.

S'il est possible que l'utilisateur change de fuseau horaire, vous devrez peut-être aussi stocker l'identifiant du fuseau horaire dans la base de données du client. Mais vous ne l'utiliserez que pendant la conversion. Il n'est pas nécessaire de l'envoyer au serveur, sauf si vous devez modifier ces valeurs sur le serveur ou dans un autre client.

N'essayez pas de stocker l'heure sur le client dans l'heure locale du client. Vous rencontrerez des abiguités. Par exemple, lorsque l'heure d'été recule, vous ne voulez pas avoir deux heures UTC différentes pour la même heure locale.

Answer 3

Pourquoi ne pas utiliser datetime et toujours stocker la valeur en tant que valeur UTC, ce qui permet de la formater en fonction du fuseau horaire de l'utilisateur final (affichage) lorsque cela est nécessaire.