63
4.1 Modélisation de la base de données
SET @vch = @ch
SELECT DATALENGTH(@vch) –- 20 !
Ce comportement est toujours valable dans le cas de chaînes UNICODE, ou lors
du mélange de chaînes ANSI avec des chaînes UNICODE, sauf dans le cas du LIKE !
Dans ce cas, les espaces finaux sont importants. Il s’agit d’une conformité avec la
norme SQL-92 (implémentée seulement pour UNICODE…) :
DECLARE @vch varchar(50)
DECLARE @nvch nvarchar(100)
SET @vch = 'salut!'
SET @nvch = 'salut! '
IF @vch = @nvch PRINT 'ok'; -- ça marche...
IF @vch LIKE @nvch PRINT 'ok' – ça ne marche pas...
Donc, utilisez les '%' pour obtenir des résultats conformes à vos attentes dans ces
cas.
Qu’en est-il donc de l’utilité du RTRIM dans la récupération ou l’insertion de
données ? Le RTRIM est inutile dans un traitement de CHAR, puisque le moteur de stockage ajoute de toute manière des espaces pour compléter la donnée. Par contre, pour
l’insertion ou l’affichage de VARCHAR, un RTRIM peut être utile si vous soupçonnez que
les chaînes insérées peuvent contenir des espaces. Comme nous le voyons dans
l’exemple, les espaces explicites à la fin d’une chaîne sont conservés dans le VARCHAR.
Cela inclut le cas où vous copiez une valeur d’un type CHAR vers un type VARCHAR : les
espaces sont conservés. Méfiez-vous de ne pas alourdir inutilement vos tables en
oubliant ce détail lors de l’importation ou de l’échange de données.
Note – Ce comportement correspond au cas où l’option SET ANSI_PADDING était
activée lors de la création de la colonne ou de la variable. Cette option est par
défaut à ON, et il est recommandé de la laisser ainsi, pour garantir un comportement cohérent des colonnes, en accord avec la norme SQL.
Vous pouvez vérifier vos colonnes de type VARCHAR avec une requête comme
celle-ci :
SELECT
AVG(DATALENGTH(EmailAddress)) as AvgDatalength,
AVG(LEN(EmailAddress)) as AvgLen,
SUM(DATALENGTH(EmailAddress)) - SUM(LEN(EmailAddress)) as Spaces,
COLUMNPROPERTY(OBJECT_ID('Person.Contact'),
'EmailAddress', 'precision') as ColumnLength
FROM Person.Contact;
4.1 Modélisation de la base de données
SET @vch = @ch
SELECT DATALENGTH(@vch) –- 20 !
Ce comportement est toujours valable dans le cas de chaînes UNICODE, ou lors
du mélange de chaînes ANSI avec des chaînes UNICODE, sauf dans le cas du LIKE !
Dans ce cas, les espaces finaux sont importants. Il s’agit d’une conformité avec la
norme SQL-92 (implémentée seulement pour UNICODE…) :
DECLARE @vch varchar(50)
DECLARE @nvch nvarchar(100)
SET @vch = 'salut!'
SET @nvch = 'salut! '
IF @vch = @nvch PRINT 'ok'; -- ça marche...
IF @vch LIKE @nvch PRINT 'ok' – ça ne marche pas...
Donc, utilisez les '%' pour obtenir des résultats conformes à vos attentes dans ces
cas.
Qu’en est-il donc de l’utilité du RTRIM dans la récupération ou l’insertion de
données ? Le RTRIM est inutile dans un traitement de CHAR, puisque le moteur de stockage ajoute de toute manière des espaces pour compléter la donnée. Par contre, pour
l’insertion ou l’affichage de VARCHAR, un RTRIM peut être utile si vous soupçonnez que
les chaînes insérées peuvent contenir des espaces. Comme nous le voyons dans
l’exemple, les espaces explicites à la fin d’une chaîne sont conservés dans le VARCHAR.
Cela inclut le cas où vous copiez une valeur d’un type CHAR vers un type VARCHAR : les
espaces sont conservés. Méfiez-vous de ne pas alourdir inutilement vos tables en
oubliant ce détail lors de l’importation ou de l’échange de données.
Note – Ce comportement correspond au cas où l’option SET ANSI_PADDING était
activée lors de la création de la colonne ou de la variable. Cette option est par
défaut à ON, et il est recommandé de la laisser ainsi, pour garantir un comportement cohérent des colonnes, en accord avec la norme SQL.
Vous pouvez vérifier vos colonnes de type VARCHAR avec une requête comme
celle-ci :
SELECT
AVG(DATALENGTH(EmailAddress)) as AvgDatalength,
AVG(LEN(EmailAddress)) as AvgLen,
SUM(DATALENGTH(EmailAddress)) - SUM(LEN(EmailAddress)) as Spaces,
COLUMNPROPERTY(OBJECT_ID('Person.Contact'),
'EmailAddress', 'precision') as ColumnLength
FROM Person.Contact;
