Discussion :

[galactica1]

Bonsoir chers tous

j'ai un p'tit souci j'arrive pas a concaténer deux champs de type string sur sql server 2008
quelqu'un pourrait-il m'aider
je vous laisse mon code

Code :

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

select matricule,nom +'  '+prenom AS noms from ETUDIANT

[Invité]

Avec autant d'indices, je vais sortir ma boule de cristal...
Message d'erreur, s'il y en a un... En tout cas, une idée du résultat pourrait aider.
Types des champs ?
Est-ce que l'un des deux est NULL ?
Et y a pas de type string en sql server, jusqu'à nouvel ordre

[StringBuilder]

Déjà, si on veut quel chose de lisible et sémantiquement correct, on ne concatène pas en faisant des + mais en utilisant la fonction CONCAT.

Car si demain tu veux concaténer 2 + '5' tu auras 7 au lieu de '25'...

[galactica1]

Avec autant d'indices, je vais sortir ma boule de cristal...
Message d'erreur, s'il y en a un... En tout cas, une idée du résultat pourrait aider.
Types des champs ?
Est-ce que l'un des deux est NULL ?
Et y a pas de type string en sql server, jusqu'à nouvel ordre

il n'y a pas de message d'erreur. En résultat je n'est pas la concaténation du nom et du prénom,seul le nom s'affiche. Pour résoudre ce problème j'ai utilisé la fonction RTRIM

[SQLpro]

C'est normal, si vos colonnes (et non"champs" qui est pour laespaysans) sont de type CHAR, les blancs seront conservés.

A +

[StringBuilder]

Accessoirement, mise à part pour quelques cas précis où le nombre de caractères est à la fois petit et figé, le type CHAR() est à considérer comme déprécié.
C'est un résidu des bases fichier, et n'a aujourd'hui plus vraiment de raison d'être… Même les performances, qui autrefois était largement meilleures avec ce type, sont discutables en raison de la place perdue (aussi bien sur le disque qu'en mémoire).

Grossomodo, CHAR n'est à utiliser qu'avec des colonnes types genre "classification ABC" ou éventuellement segmentation comptable (quand on utilise des numéros de comptes de taille fixe).

Pour stocker des noms et prénoms, c'est une hérésie, et comme votre cas en témoigne, ça apporte bien plus de problèmes qu'autrechose !

[SQLpro]

Accessoirement, mise à part pour quelques cas précis où le nombre de caractères est à la fois petit et figé, le type CHAR() est à considérer comme déprécié.
C'est un résidu des bases fichier, et n'a aujourd'hui plus vraiment de raison d'être… Même les performances, qui autrefois était largement meilleures avec ce type, sont discutables en raison de la place perdue (aussi bien sur le disque qu'en mémoire).

Grossomodo, CHAR n'est à utiliser qu'avec des colonnes types genre "classification ABC" ou éventuellement segmentation comptable (quand on utilise des numéros de comptes de taille fixe).

Pour stocker des noms et prénoms, c'est une hérésie, et comme votre cas en témoigne, ça apporte bien plus de problèmes qu'autrechose !

Pas du tout d'accord.

En effet,...

• l'usage systématique de colonnes de type VARCHAR conduit immanquablement à de la fragmentation et des lectures très contre performantes parce que faites en "zig-zag".
• de plus le VARCHAR nécessite 2 octets de plus que le CHAR pour stocker les mêmes informations.
• même sans fragmentation, la recherche est moins efficace que dans un char.
• pour couronner le tout, lors de certaines opérations internes (GROUPAGE, DISTINCT, ORDER BY) il faut aligner les VARCHAR pour éviter des lectures en drapeau ce qui pose des problèmes de performances !

Je ne cesse de montrer dans mes audits ce genre d'horreur qu'est l'utilisation imbécile et systématique du VARCHAR...

A +

[galactica1]

Accessoirement, mise à part pour quelques cas précis où le nombre de caractères est à la fois petit et figé, le type CHAR() est à considérer comme déprécié.
C'est un résidu des bases fichier, et n'a aujourd'hui plus vraiment de raison d'être… Même les performances, qui autrefois était largement meilleures avec ce type, sont discutables en raison de la place perdue (aussi bien sur le disque qu'en mémoire).

Grossomodo, CHAR n'est à utiliser qu'avec des colonnes types genre "classification ABC" ou éventuellement segmentation comptable (quand on utilise des numéros de comptes de taille fixe).

Pour stocker des noms et prénoms, c'est une hérésie, et comme votre cas en témoigne, ça apporte bien plus de problèmes qu'autrechose !

bon j'ai utilisé le type VARCHAR mais désormais je ferai NVARCHAR

[SQLpro]

bon j'ai utilisé le type VARCHAR mais désormais je ferai NVARCHAR

Le NVARCHAR n'a d'intérêt que si vous stockez des données littérale avec un autre alphabet que le latin (hébreu, arabe, chinois…).
Sinon, il prend deux fois plus de place et par conséquent se trouve être deux fois moins performant….

A +

[StringBuilder]

Pas du tout d'accord.

En effet,...
[…]

Je ne cesse de montrer dans mes audits ce genre d'horreur qu'est l'utilisation imbécile et systématique du VARCHAR...

A +

wow !

Je tombe de haut !
J'étais absolument persuadé du contraire…

Désolé si j'ai dit des bêtises alors.

Par contre, je trouve ça hyper contraignant pour tout ce qui est donnée de taille variable difficile à prédire à l'avance.

J'ai pour habitude d'utiliser des varchar de taille plus ou moins importante pour les libellés de taille "aléatoire", genre nom de ville, de rue, nom, prénom.

En effet, si je veux ceinture bretelle, je vais devoir avoir une colonne d'une taille au minimum aussi grande (et généralement plus) afin de stocker sans problème ma donnée, même si demain cette longueur maximum change.

Exemple : https://fr.wikipedia.org/wiki/Liste_...les_plus_longs

Cela implique donc pour une ville, il faudrait un NCHAR(326) puisque le nom de la ville le plus long fait 163 caractères dans un alphabet non latin : "กรุงเทพมหานคร อมรรัตนโกสินทร์ มหินทรายุธยามหาดิลก ภพนพรัตน์ ราชธานีบุรีรมย์ อุดมราชนิเวศน์ มหาสถาน อมรพิมาน อวตารสถิต สักกะทัตติยะ วิษณุกรรมประสิทธิ์". Et vu que c'est Bangkok, j'ai pas mal de chances à voir débarquer un jour cette valeur sans mon SI si je travaille à l'international.
Si on stocke la version française, ça fait même "Ville des anges, grande ville, résidence du Bouddha d'émeraude, ville imprenable du dieu Indra, grande capitale du monde ciselée de neuf pierres précieuses, ville heureuse, généreuse dans l'énorme Palais Royal pareil à la demeure céleste, règne du dieu réincarné, ville dédiée à Indra et construite par Vishnukarn" ce qui conne un CHAR(313) ou même un NCHAR(626) si je veux pouvoir stocker indifféremment l'un ou l'autre.

La vie étant ainsi faire qu'une coulée de boue pourrait bien emporter la moitié de cette ville qui pourrait être renommée avec quelques dizaines de caractères de plus pour dire quel divinité a exprimé sa colère et quel saint l'a reconstruite…

Bref, moi je me pose pas de question, face à un cas pareil, je pars sur un VARCHAR(400) ou NVARCHAR(800), sachant que pour stocker la ville de Pi, je n'utiliserai sur disque que 4 ou 6 octets là où avec du (N)CHAR j'aurais la même place occupée pour chaque ville, y compris pour la large majorité qui ne dépasse pas 10 ou 15 caractères…

Sans oublier que si je me trouve confronté à ce genre de problème chaque colonne de ma table, la taille d'une ligne va à coup sûr dépasser la taille maximum, et je vais m'exposer à tout un tas de problèmes et contraintes supplémentaires, que j'ai peu de chance d'avoir avec du (N)VARCAR car j'ai peu de chances que la personne avec le nom le plus long du monde habite dans la rue avec le nom le plus long au monde dans la ville avec le nom le plus long, le pays le plus long et le je ne sais pas le plus long.

Et sans aller jusque dans ces extrêmes, j'avoue que je suis perplexe que de devoir réserver 40 ou 80 caractères pour chaque colonne (nom, prénom, ville) quand 80% des lignes n'auront peut-être même pas 40 caractères utilisés sur l'ensemble des trois colonnes soit plus judicieux que d'utiliser l'espace de stockage de la manière la plus juste possible...

[SQLpro]

wow !

Je tombe de haut !
J'étais absolument persuadé du contraire…

Désolé si j'ai dit des bêtises alors.

Par contre, je trouve ça hyper contraignant pour tout ce qui est donnée de taille variable difficile à prédire à l'avance.

J'ai pour habitude d'utiliser des varchar de taille plus ou moins importante pour les libellés de taille "aléatoire", genre nom de ville, de rue, nom, prénom.

En effet, si je veux ceinture bretelle, je vais devoir avoir une colonne d'une taille au minimum aussi grande (et généralement plus) afin de stocker sans problème ma donnée, même si demain cette longueur maximum change.

Exemple : https://fr.wikipedia.org/wiki/Liste_...les_plus_longs

Cela implique donc pour une ville, il faudrait un NCHAR(326) ...

Pas si simple !

En effet, tout dépend de l'utilisation que tu fais des données.

Pour une ville apparaissant dans une adresse postale, tu devra impérativement te limiter à 38 caractères, code postal inclus.
Pour un toponyme de GPS par exemple, pourquoi pas un NVARCHAR(400)
Si tu fais des recherches intensives sur le toponymes alors la question est : dois-je mettre du NCHAR ?

L'algorithme utilisé en interne par SQL Server pour certaines opérations dans le cas de type de données de taille variable est de l'aligner à la moitié de la longueur max.

Personnellement je met du CHAR pour les villes, car je sais que c'est souvent recherché.
Je met du varchar sur les libellé de rue et autres éléments de l'adresse, car c'est rarement recherché.
Et je met du type fxe sur tout ce qui est de 8 caractères ou moins.

A +

[StringBuilder]

Merci pour ces précisions

Bon, ça me rassure.

Je suis actuellement en train de me former sur un ERP qui use et abuse des CHAR(X) (au point que même les types décimaux sont stockés de la sorte (mais étrangement, pas les types date qui pour une fois sont stockés avec le type adéquat ).

Vu que ces choix parfois discutables étaient hérités du passé, quand les données étaient gérées dans des fichiers séquentiels indexés, j'avais un peu raccourcis l'histoire.