La meilleure façon de stocker les données de date/heure dans SQL Server 2008 R2 et SQL Server Compact 4

Nous sommes à développer une application en C# 4 qui utilise SQL Server 2008 R2 dans le backend. SQL Server Compact 4 est également utilisé pour les clients déconnectés dans quelques très rares scénarios. Nous nous demandons quelle est la meilleure façon de stocker les données de date/heure dans ces bases de données, de sorte que:

  1. De données contenant les différents décalages temporels (venant de différents fuseaux horaires) peuvent co-exister bien. Cela signifie classés et comparés.
  2. De données dans SQL Server 2008 R2 et SQL Server Compact 4 peuvent être transférés de façon transparente; c'est une exigence secondaire qui ne doivent pas compromettre le design choisi.

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 classer les évènements qui ont été générés à partir des fuseaux horaires différents et donc avoir différents décalages temporels.

Nous avons considéré le datetimeoffset type de données, car il stocke le décalage de temps et parce que cela correspond bien à l' .NET DateTimeOffset. Cependant, il n'est pas pris en charge dans SQL Server Compact 4. Une autre solution serait de supprimer l'offset des informations à partir de la base de données et l'utilisation d'un simple datetime type de données, de sorte que chaque morceau de données dans la base de données est normalisée, et les problèmes avec les Compact sont de moins en moins. Toutefois, cela introduit le problème de décalage d'info aurait besoin d'être reconstruit en quelque sorte sur la récupération avant que l'utilisateur voit les données.

Donc ma question est, existe-il des pratiques exemplaires et des directives sur la façon de stocker les valeurs de date/heure dans SQL Server, tenant compte du fait que nous allons devoir traiter avec des fuseaux horaires différents, et de faire de l'interopérabilité entre 2008 R2 et 4 Compact aussi facile que possible?

Merci.

Notez que datetimeoffset n'a pas vraiment de stocker une zone de temps - magasins de décalage. Que ne vous dit pas de fuseau horaire, il a été observé, c'est à dire que l'heure locale est de 10 minutes plus tard, lorsque le décalage ont changé. Ce sont ces valeurs censé représenter? Juste instants dans le temps? Fondamentalement, vous avez besoin de garder le décalage d'origine, ou vous êtes seulement intéressés à l'instant où quelque chose s'est produit?
Vous avez raison, je dois avouer que je n'avais pas regardé de cette façon. Nous sommes intéressés de connaître l'heure locale de l'événement, mais doivent également être en mesure de comparer les temps de chaque événement à d'autres événements qui peuvent avoir été produits à des endroits différents et, par conséquent, en vertu des fuseaux horaires différents (et donc ont des positions différentes).
Ok - si vous besoin de l'heure locale, alors vous avez besoin pour stocker le décalage d'une manière ou d'une autre. Ensuite, vous devez penser que vous devez être en mesure de requête ce sont les données sur l'heure locale - par exemple, vous pouvez stocker une valeur de type DateTime dans l'heure UTC et l'offset dans une colonne séparée... que ferait-il facile de l'ordre mondial, mais relativement difficile de rechercher localement...
Nous serions plutôt d'optimiser les locaux de fois qu'mondial de la comparaison de tri/classement. Peut-être le stockage DateTime dans de temps, et de compenser dans une colonne distincte? Ou, alternativement, DateTimeOffset? Toutes les lignes directrices et des pratiques exemplaires sur la façon dont SQL Server DateTimeOffset œuvres et s'intègre avec .NET?
L'utilisation de SqlServerCE est pourquoi je suggère de ne pas utiliser DateTimeOffset. Mais oui, vous pourrez utiliser un local de type DateTime et un décalage de soustraire pour obtenir de l'UTC.

OriginalL'auteur CesarGon | 2013-06-27

  1. 5

    Il semble que les points pertinents sont:

    • Vos données entrantes est un bon ajustement pour DateTimeOffset
    • Vous ne se soucient que le décalage à l'époque, de sorte que vous n'avez pas besoin d'un réel fuseau horaire. (Décalage n'est pas une zone de temps.)
    • Vous ne de soins à ce sujet décalage d'origine - vous ne pouvez pas simplement normaliser tout à l'heure UTC et l'ignorer le décalage entièrement.
    • Vous voulez interroger sur la local temps.

    Il ne sonne comme DateTimeOffset est essentiellement le type le plus approprié dans ce cas. Assurez-vous que tout le monde dans l'équipe est claire sur ce qu'elle signifie que le décalage est le décalage lorsque les données ont été initialement reçus. Si vous souhaitez afficher cet instant dans le temps d'une différents de fuseau horaire, vous devez revenir en arrière à l'UTC, et découvrir ce que le décalage serait que du temps d'affichage de la zone. Il est facile d'obtenir confus quant à ce genre de chose 🙂

    Si vous avez besoin de conserver les données SqlServerCE avec une pleine fidélité, vous aurez probablement envie d'un champ DateTime et puis un champ distinct pour le décalage (par exemple, en quelques minutes, ou comme un laps de Temps si SqlServerCE soutient que).

    Merci à vous, ce qui fait beaucoup de sens pour moi. Nous aurons besoin de trouver un moyen de contourner SQL Server CE, mais ce n'est pas une grosse affaire.

    OriginalL'auteur Jon Skeet

  2. 1

    Vous êtes probablement droit d'utiliser DateTimeOffset sur le serveur. Vous pouvez aussi lire ma réponse sur DateTime vs DateTimeOffset.

    Sur le client, où vous utilisez SQLCE, stocker une DateTime avec des valeurs d'UTC. Lorsque vous envoyez les données sur le serveur, vous pouvez utiliser le fuseau horaire local du client afin de déterminer le DateTimeOffset que la valeur UTC correspond à.

    Si il est possible que l'utilisateur peut changer les fuseaux horaires, alors vous pourriez aussi avoir besoin de stocker le fuseau horaire de l'id dans la base de données client. Mais vous pouvez simplement utiliser ce lors de la conversion. Il n'y a pas besoin de l'envoyer au serveur, à moins que vous pourriez être en train de modifier ces valeurs sur le serveur ou dans un autre client.

    N'essayez pas de stocker la fois sur le client dans l'heure locale du client. Vous rencontrerez abiguities. Par exemple, lorsque l'heure d'été roule en arrière, vous ne voulez pas y a deux sortes de temps UTC pour le même temps.

    Merci pour les bons conseils concernant le client. Je suis en train de regarder votre réponse maintenant.

    OriginalL'auteur Matt Johnson

  3. 0

    Pourquoi ne pas utiliser datetime et toujours conserver la valeur comme une valeur UTC, puis vous pouvez les mettre en forme pour les utilisateurs finaux (affichage) fuseau horaire lorsque requis.

    Eh bien, je préfère éviter de reproduire quelque chose qui est déjà mis en œuvre par le backend. SQL Server et .NET apparemment gérer les fuseaux horaires pour vous avec le DateTimeOffset types de données. Je voudrais seulement revenir à gérer manuellement, comme vous le suggérez, si elle avait des avantages évidents.
    Eh bien, SQLCE prend uniquement en charge datetime, de sorte que la seule autre option est de stocker les valeurs datetime dans un nchar(34) de la colonne, à l'aide de cette mise en forme: dto.ToString("yyyy-MM-dd HH:mm:ss.fffffff zzz", Système.De la mondialisation.CultureInfo.InvariantCulture)
    😉 En effet, le fait que SQLCE ne prend pas en charge datetimeoffset est une bonne raison d'aller pour un all-over de type datetime solution et stocker le décalage ailleurs, comme vous le suggérez. Mais j'aimerais explorer d'autres options et d'avoir quelques idées sur ce que les avantages et les inconvénients de chaque option aurait.

    OriginalL'auteur ErikEJ