Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

  1. #1
    Membre à l'essai
    Homme Profil pro
    Administrateur de base de données
    Inscrit en
    février 2017
    Messages
    10
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 32
    Localisation : Gabon

    Informations professionnelles :
    Activité : Administrateur de base de données

    Informations forums :
    Inscription : février 2017
    Messages : 10
    Points : 11
    Points
    11

    Par défaut Concaténation de deux champs

    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

  2. #2
    Membre expert Avatar de 7gyY9w1ZY6ySRgPeaefZ
    Homme Profil pro
    dba
    Inscrit en
    juillet 2007
    Messages
    4 317
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Canada

    Informations professionnelles :
    Activité : dba

    Informations forums :
    Inscription : juillet 2007
    Messages : 4 317
    Points : 3 927
    Points
    3 927

    Par défaut

    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

  3. #3
    Expert confirmé
    Avatar de StringBuilder
    Homme Profil pro
    Chef de projets
    Inscrit en
    février 2010
    Messages
    3 286
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 39
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : Chef de projets
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : février 2010
    Messages : 3 286
    Points : 5 375
    Points
    5 375
    Billets dans le blog
    1

    Par défaut

    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'...
    On ne jouit bien que de ce qu’on partage.

  4. #4
    Membre à l'essai
    Homme Profil pro
    Administrateur de base de données
    Inscrit en
    février 2017
    Messages
    10
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 32
    Localisation : Gabon

    Informations professionnelles :
    Activité : Administrateur de base de données

    Informations forums :
    Inscription : février 2017
    Messages : 10
    Points : 11
    Points
    11

    Par défaut

    Citation Envoyé par 7gyY9w1ZY6ySRgPeaefZ Voir le message
    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

  5. #5
    Rédacteur
    Avatar de SQLpro
    Homme Profil pro
    Expert SGBDR & SQL, spécialiste Microsoft SQL Server
    Inscrit en
    mai 2002
    Messages
    18 334
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Var (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Expert SGBDR & SQL, spécialiste Microsoft SQL Server
    Secteur : Conseil

    Informations forums :
    Inscription : mai 2002
    Messages : 18 334
    Points : 42 847
    Points
    42 847

    Par défaut

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

    A +
    Frédéric Brouard - SQLpro - ARCHITECTE DE DONNÉES - expert SGBDR et langage SQL
    Le site sur les SGBD relationnels et le langage SQL: http://sqlpro.developpez.com/
    Blog SQL, SQL Server, SGBDR : http://blog.developpez.com/sqlpro
    Expert Microsoft SQL Server - M.V.P. (Most valuable Professional) MS Corp.
    Entreprise SQL SPOT : modélisation, conseils, audit, optimisation, formation...
    * * * * * Enseignant CNAM PACA - ISEN Toulon - CESI Aix en Provence * * * * *

  6. #6
    Expert confirmé
    Avatar de StringBuilder
    Homme Profil pro
    Chef de projets
    Inscrit en
    février 2010
    Messages
    3 286
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 39
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : Chef de projets
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : février 2010
    Messages : 3 286
    Points : 5 375
    Points
    5 375
    Billets dans le blog
    1

    Par défaut

    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 !
    On ne jouit bien que de ce qu’on partage.

  7. #7
    Rédacteur
    Avatar de SQLpro
    Homme Profil pro
    Expert SGBDR & SQL, spécialiste Microsoft SQL Server
    Inscrit en
    mai 2002
    Messages
    18 334
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Var (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Expert SGBDR & SQL, spécialiste Microsoft SQL Server
    Secteur : Conseil

    Informations forums :
    Inscription : mai 2002
    Messages : 18 334
    Points : 42 847
    Points
    42 847

    Par défaut

    Citation Envoyé par StringBuilder Voir le message
    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 +
    Frédéric Brouard - SQLpro - ARCHITECTE DE DONNÉES - expert SGBDR et langage SQL
    Le site sur les SGBD relationnels et le langage SQL: http://sqlpro.developpez.com/
    Blog SQL, SQL Server, SGBDR : http://blog.developpez.com/sqlpro
    Expert Microsoft SQL Server - M.V.P. (Most valuable Professional) MS Corp.
    Entreprise SQL SPOT : modélisation, conseils, audit, optimisation, formation...
    * * * * * Enseignant CNAM PACA - ISEN Toulon - CESI Aix en Provence * * * * *

  8. #8
    Membre à l'essai
    Homme Profil pro
    Administrateur de base de données
    Inscrit en
    février 2017
    Messages
    10
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 32
    Localisation : Gabon

    Informations professionnelles :
    Activité : Administrateur de base de données

    Informations forums :
    Inscription : février 2017
    Messages : 10
    Points : 11
    Points
    11

    Par défaut

    Citation Envoyé par StringBuilder Voir le message
    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

  9. #9
    Rédacteur
    Avatar de SQLpro
    Homme Profil pro
    Expert SGBDR & SQL, spécialiste Microsoft SQL Server
    Inscrit en
    mai 2002
    Messages
    18 334
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Var (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Expert SGBDR & SQL, spécialiste Microsoft SQL Server
    Secteur : Conseil

    Informations forums :
    Inscription : mai 2002
    Messages : 18 334
    Points : 42 847
    Points
    42 847

    Par défaut

    Citation Envoyé par galactica1 Voir le message
    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 +
    Frédéric Brouard - SQLpro - ARCHITECTE DE DONNÉES - expert SGBDR et langage SQL
    Le site sur les SGBD relationnels et le langage SQL: http://sqlpro.developpez.com/
    Blog SQL, SQL Server, SGBDR : http://blog.developpez.com/sqlpro
    Expert Microsoft SQL Server - M.V.P. (Most valuable Professional) MS Corp.
    Entreprise SQL SPOT : modélisation, conseils, audit, optimisation, formation...
    * * * * * Enseignant CNAM PACA - ISEN Toulon - CESI Aix en Provence * * * * *

  10. #10
    Expert confirmé
    Avatar de StringBuilder
    Homme Profil pro
    Chef de projets
    Inscrit en
    février 2010
    Messages
    3 286
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 39
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : Chef de projets
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : février 2010
    Messages : 3 286
    Points : 5 375
    Points
    5 375
    Billets dans le blog
    1

    Par défaut

    Citation Envoyé par SQLpro Voir le message
    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...
    On ne jouit bien que de ce qu’on partage.

  11. #11
    Rédacteur
    Avatar de SQLpro
    Homme Profil pro
    Expert SGBDR & SQL, spécialiste Microsoft SQL Server
    Inscrit en
    mai 2002
    Messages
    18 334
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Var (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Expert SGBDR & SQL, spécialiste Microsoft SQL Server
    Secteur : Conseil

    Informations forums :
    Inscription : mai 2002
    Messages : 18 334
    Points : 42 847
    Points
    42 847

    Par défaut

    Citation Envoyé par StringBuilder Voir le message
    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 +
    Frédéric Brouard - SQLpro - ARCHITECTE DE DONNÉES - expert SGBDR et langage SQL
    Le site sur les SGBD relationnels et le langage SQL: http://sqlpro.developpez.com/
    Blog SQL, SQL Server, SGBDR : http://blog.developpez.com/sqlpro
    Expert Microsoft SQL Server - M.V.P. (Most valuable Professional) MS Corp.
    Entreprise SQL SPOT : modélisation, conseils, audit, optimisation, formation...
    * * * * * Enseignant CNAM PACA - ISEN Toulon - CESI Aix en Provence * * * * *

  12. #12
    Expert confirmé
    Avatar de StringBuilder
    Homme Profil pro
    Chef de projets
    Inscrit en
    février 2010
    Messages
    3 286
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 39
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : Chef de projets
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : février 2010
    Messages : 3 286
    Points : 5 375
    Points
    5 375
    Billets dans le blog
    1

    Par défaut

    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.
    On ne jouit bien que de ce qu’on partage.

+ Répondre à la discussion
Cette discussion est résolue.

Discussions similaires

  1. Réponses: 2
    Dernier message: 30/05/2011, 14h46
  2. concaténation de deux champs dans une liste déroulante
    Par midotoon dans le forum Struts 1
    Réponses: 3
    Dernier message: 02/09/2008, 17h18
  3. Concaténation de deux champs dataTextField d'une listbox
    Par douha dans le forum Windows Forms
    Réponses: 3
    Dernier message: 27/05/2008, 17h30
  4. [C#][2.0]Lier une concaténation de deux champs
    Par Troopers dans le forum Accès aux données
    Réponses: 1
    Dernier message: 04/04/2007, 18h08
  5. Concaténation de deux champs
    Par Ric21 dans le forum Access
    Réponses: 12
    Dernier message: 22/01/2007, 17h31

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo