65
4.1 Modélisation de la base de données
Inversement, des colonnes variables peuvent provoquer de la fragmentation dans
les pages ou dans les extensions, selon que les mises à jour modifient la taille de la
ligne. Donc, songez à tester régulièrement la fragmentation, et à défragmenter vos
tables lorsque nécessaire. Nous aborderons ce point dans le chapitre 6.
Valeurs temporelles
La plupart des bases de données doivent stocker des données temporelles. En SQL
Server 2005, vous disposez de deux types de données : DATETIME et SMALLDATETIME.
Ne confondez pas avec TIMESTAMP, qui contrairement à d’autres SGBDR et à la
norme SQL, ne correspond pas dans SQL Server à un type de données de date, mais
à un compteur unique par base de données, incémenté automatiquement à la modification de toute colonne portant ce type de données. DATETIME est codé sur huit
octets, quatre octets stockant la date, et quatre l’heure. SMALLDATETIME est codé sur
quatre octets, deux octets stockant la date, et deux l’heure. Cela permet au type
DATETIME de couvrir une période allant du 1 er janvier 1753 au 31 décembre 9999,
avec une précision de la partie heure de 3,33 millisecondes. Le type SMALLDATETIME
va du 1 janvier 1900 au 6 juin 2079, avec une précision à la minute. Il n’y a pas, en
SQL Server 2005, de possibilité de stocker une date séparément d’une heure, sauf à
l’adapter dans un autre type de données (en CHAR par exemple). Cela reste très peu
utilisé en pratique, car posant le problème de la manipulation des dates : comment
trouver le nombre de jours séparant deux CHAR ? L’habitude prise est donc d’exprimer
des dates seulement en spécifiant une heure de 00:00:00, et les heures seules en
passant une date au 1 er janvier 1900.
Le type SMALLDATIME est deux fois plus court que le type DATETIME et est donc à
préférer tant que possible. Il est idéal pour exprimer toute date/heure dont la granularité est au-dessus de la minute. Si vous devez stocker des temps plus précis, comme par
exemple des lignes de journalisation, n’utilisez surtout pas SMALLDATETIME : il vous
serait impossible de trier correctement les lignes à l’intérieur de la même minute. Il
fut un temps où certains langages client, comme Visual Basic, ne manipulaient pas
correctement le type SMALLDATETIME. Ce temps est révolu depuis longtemps.
Le type DATETIME est plus précis, mais pas exactement précis. Méfiez-vous de son
arrondi : vous pouvez passer, en chaîne de caractères, une valeur de temps en millisecondes, qui sera arrondie automatiquement par SQL Server, ce qui peut vous réserver des surprises. Imaginez que votre application cliente soit précise à la
milliseconde, et insère deux lignes, à deux millisecondes près. Pour SQL Server, la
valeur DATETIME sera la même, comme le prouve l’exemple suivant :
DECLARE @date1 datetime
DECLARE @date2 datetime
SET @date1 = '20071231 23:59:59:999'
SET @date2 = '20080101 00:00:00:001'
IF @date1 = @date2
PRINT 'pas de différence'
4.1 Modélisation de la base de données
Inversement, des colonnes variables peuvent provoquer de la fragmentation dans
les pages ou dans les extensions, selon que les mises à jour modifient la taille de la
ligne. Donc, songez à tester régulièrement la fragmentation, et à défragmenter vos
tables lorsque nécessaire. Nous aborderons ce point dans le chapitre 6.
Valeurs temporelles
La plupart des bases de données doivent stocker des données temporelles. En SQL
Server 2005, vous disposez de deux types de données : DATETIME et SMALLDATETIME.
Ne confondez pas avec TIMESTAMP, qui contrairement à d’autres SGBDR et à la
norme SQL, ne correspond pas dans SQL Server à un type de données de date, mais
à un compteur unique par base de données, incémenté automatiquement à la modification de toute colonne portant ce type de données. DATETIME est codé sur huit
octets, quatre octets stockant la date, et quatre l’heure. SMALLDATETIME est codé sur
quatre octets, deux octets stockant la date, et deux l’heure. Cela permet au type
DATETIME de couvrir une période allant du 1 er janvier 1753 au 31 décembre 9999,
avec une précision de la partie heure de 3,33 millisecondes. Le type SMALLDATETIME
va du 1 janvier 1900 au 6 juin 2079, avec une précision à la minute. Il n’y a pas, en
SQL Server 2005, de possibilité de stocker une date séparément d’une heure, sauf à
l’adapter dans un autre type de données (en CHAR par exemple). Cela reste très peu
utilisé en pratique, car posant le problème de la manipulation des dates : comment
trouver le nombre de jours séparant deux CHAR ? L’habitude prise est donc d’exprimer
des dates seulement en spécifiant une heure de 00:00:00, et les heures seules en
passant une date au 1 er janvier 1900.
Le type SMALLDATIME est deux fois plus court que le type DATETIME et est donc à
préférer tant que possible. Il est idéal pour exprimer toute date/heure dont la granularité est au-dessus de la minute. Si vous devez stocker des temps plus précis, comme par
exemple des lignes de journalisation, n’utilisez surtout pas SMALLDATETIME : il vous
serait impossible de trier correctement les lignes à l’intérieur de la même minute. Il
fut un temps où certains langages client, comme Visual Basic, ne manipulaient pas
correctement le type SMALLDATETIME. Ce temps est révolu depuis longtemps.
Le type DATETIME est plus précis, mais pas exactement précis. Méfiez-vous de son
arrondi : vous pouvez passer, en chaîne de caractères, une valeur de temps en millisecondes, qui sera arrondie automatiquement par SQL Server, ce qui peut vous réserver des surprises. Imaginez que votre application cliente soit précise à la
milliseconde, et insère deux lignes, à deux millisecondes près. Pour SQL Server, la
valeur DATETIME sera la même, comme le prouve l’exemple suivant :
DECLARE @date1 datetime
DECLARE @date2 datetime
SET @date1 = '20071231 23:59:59:999'
SET @date2 = '20080101 00:00:00:001'
IF @date1 = @date2
PRINT 'pas de différence'