Discussion :

[newproger]

Bonjour,

Je me demande ce qui est le plus performant:
- utiliser une colonne DateTime2
- utiliser 2 colonnes Date + Time

Si ces informations sont dans un index et que des fonctions sont appliquer (selection des matin sur un mois, selection dans jour en particulier, ...) , laquelle des methodes permet sur une table de grande quantité (plusieurs dizaines de millions de lignes) une meilleure perf et de profiter des index (donc exit les fonction Year, Month, Hour, ou les cast).

Merci

[hmira]

Si votre colonne représente, au sens usuel, une indication du temps (hormis le temps perdu et le temps des malentendus), visant à définir une date et heure, minute et une fraction de secondes, c'est à dire un point précis dans le temps en tant qu'espace topologie, alors d'après moi, ce serait très mauvaise idée de décomposer votre colonne en 2 colonnes séparées ; une de type Date et l'autre de type Time.

En effet, cela va avoir un impact sur votre code. Cela va complexifier votre Code. Par Exemple Sélectionner des événements entre le jour j à 23h15 et j+1 à 1h00. D'aucuns s'arracheront les cheveux pour exprimer la clause WHERE !
Alors que si vous vous utilisez le type DateTime2 avec une précision donnée, les expressions de filtre sur cette colonne deviendront assez simple.

Quant aux performances (utilisation des Indexes, etc.) vous avez tout à fait raison de vous préoccupez de cet aspect important. Il faut veiller à adopter les bonnes pratiques, ne pas utiliser des expressions NON-SARG. Il faut savoir exprimer correctement les clauses WHERE de telle sorte que l'optimiseur puisse bénéficier des indexes.
Exemple
On écrit pas

Code SQL :

Sélectionner tout - Visualiser dans une fenêtre à part

 WHERE YEAR(Col1) BETWEEN 2012 and 2014 -- mauvaise pratique !

On va remplacer la clause where ci-dessus par :

Code SQL :

Sélectionner tout - Visualiser dans une fenêtre à part

 WHERE Col1 >= '2012-01-01T00:00:00' AND Col1 < '2015-01-01T00:00:00' -- bonne pratique

La deuxième requête pourra bénéficier d'un index défini sur la colonne Col1 alors que la première Clause NON-SARG ne pourra pas bénéficier de l'index ; L'optimiseur risque de faire un Full Scan sur de la table, ce qui peut être désastreux pour les performances !

A+

[newproger]

Dans ce cas, si je devais sélectionner toutes les datas comprises entre 9H et 12H du mois de décembre par exemple, comment feriez vous ?
avec une colonne time c'est simple, mais là sans les fonctions, c'est plus compliqué.

[hmira]

Dans ce cas, si je devais sélectionner toutes les datas comprises entre 9H et 12H du mois de décembre par exemple, comment feriez vous ?
avec une colonne time c'est simple, mais là sans les fonctions, c'est plus compliqué.

On ne choisit pas le type d'une colonne en fonction des optimisations des clauses WHERE que l'on peut escompter !
Le type d'une colonne est généralement choisi en lien avec la nature et la sémantique de ce que la colonne (Attribut d'une relation) représente dans le monde réel.
Une date est une date, elle exprime un jour j
et une date-heure, minute fraction de secondes et une date-heure, minute fraction de secondes. Elle exprime un instant t dans le temps.

Quant à l'optimisation, si jamais, vous êtes confronté à des problèmes de performance sur certaines requêtes, il existe d'autres techniques comme par exemple la création de colonne calculée persistante (de type Time) sur la quelle vous pouvez bâtir des indexes. Vous pouvez ensuite, le cas échéant, pour les besoins d'optimisation et de performance, utiliser ces colonnes calculées persistantes, indexées, dans les clauses WHERE, en lieu et place des colonnes origines.

A+

[newproger]

Merci pour ces infos, je vais tenter d'en tenir compte.
Je voyais cela d'un aspect programmation de mes requêtes, ce qui n'est peut-être pas une bonne idée.

[StringBuilder]

Si vous avez besoin de faire des filtres complexes sur les dates, en grand nombre, de façon intensive, et que la granularité des heures exprimée n'est pas trop fine (pas à milliseconde), alors vous pouvez aussi passer par une table "calendrier".

Cette table va énumérer toutes les heures "possibles" entre la date la plus ancienne et la date la plus récente nécessaire au fonctionnement de votre application.
On y trouvera donc :
- Une colone datetime ou datetime2 avec l'énumération de toutes les 5 minutes entre 01/01/2000 et 31/12/2015 par exemple (ça fait pas mal de lignes !)
- Et une série de colonnes calculées, stockées, contenant par exemple : l'heure seule, la date seule, l'année, le mois, l'heure, le numéro de semaine, le jour de la semaine, si le jour est férié, etc. en fonction de vos besoins, qui seront indexées en fonction des requêtes à exécuter dessus.

Ensuite, il suffira de faire un lien entre cette table et la table dans laquelle vous stockez des dates (en prenant bien soin de stocker une clé étrangère vers le calendrier plutôt que la date).

Ainsi, vous pourrez bénéficier de bonnes performances, tout en ayant le choix, moment des requêtes d'utiliser différentes parties de la date, selon vos besoins.