IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
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

 PostgreSQL Discussion :

PostgreSQL et varchar(nn)


Sujet :

PostgreSQL

Vue hybride

Message précédent Message précédent   Message suivant Message suivant
  1. #1
    Membre averti
    Profil pro
    Inscrit en
    Mai 2009
    Messages
    38
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Mai 2009
    Messages : 38
    Par défaut PostgreSQL et varchar(nn)
    Bonjour à tous,
    Je ne savais pas trop où mettre ce message, alors comme je débute en PostgreSQL...

    Ma question concerne la gestion des varchar par PostgreSQL, je vais essayer d'être clair :

    Je voudrais savoir quel est l'impact de la longueur des champs varchar sur la rapidité de travail (en datawarehouse*) avec une base PostgreSQL.

    C'est à dire :
    vaut-il mieux déclarer :
    1 champ varchar(10)
    1 champ varchar(30)
    1 champ varchar(50)
    1 champ varchar(100)

    sachant qu'un seul de ces champs est renseigné par enregistrement,
    tantôt par une info de 10 o,
    tantôt par une info de 30 o,
    tantôt par une info de 50 o,
    tantôt par une info de 100 o

    ou déclarer un seul champ varchar(100) et tout mettre dedans quelque soit la longueur de l'info à enregistrer ?

    * base attaquée par des appli delphi.

    Merci d'avance pour votre aide.

  2. #2
    Membre Expert
    Homme Profil pro
    Inscrit en
    Septembre 2006
    Messages
    2 963
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Belgique

    Informations forums :
    Inscription : Septembre 2006
    Messages : 2 963
    Par défaut
    indépendamment de PostgreSQL :

    tant que la longueur du varchar() ne dépasse pas la limite qui provoquerait sa conversion automatique en champ TEXT (ou CLOB, ou … - suivant le RDBMS), il est totalement inutile de songer à ce genre de pseudo optimisation… (et de toute façon jamais poussé à cet extrême…)

    et spécifiquement pour PostgreSQL > v8.0 :

    Tip: There are no performance differences between these three types, apart from the increased storage size when using the blank-padded type. While character(n) has performance advantages in some other database systems, it has no such advantages in PostgreSQL. In most situations text or character varying should be used instead.
    pour les versions antérieures, lisez la doc.

    En clair : sous PostgreSQL ≥ 8.0, vous pouvez même mettre TEXT sans aucune pénalité de performance…
    la question de la longueur des VARCHAR() ne se pose donc que si vous devez en plus faire un schéma multi-RDBMS…
    si vous êtes définitivement lié à PostgreSQL : vous êtes tranquille…

  3. #3
    Membre averti
    Profil pro
    Inscrit en
    Mai 2009
    Messages
    38
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Mai 2009
    Messages : 38
    Par défaut
    Super, Merci.

    J'utiliserai donc un ou des champs en varchar(100), s'agissant de la limite max dont j'ai besoin.
    En parlant d'optimisation, je crois savoir que, à l'inverse, le problème se pose réellement pour les champs int2 et int4 :

    Je suppose que même dans PostgreSQL, il convient de faire le distingo entre les deux ?

  4. #4
    Membre averti
    Profil pro
    Inscrit en
    Mai 2009
    Messages
    38
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Mai 2009
    Messages : 38
    Par défaut
    Une petite précision :
    Si j'utilise des varchar sans préciser la taille, mes composants Delphi orientés données m'affiche un [memo] au lieu du contenu du champ.

    Voilà pourquoi j'en reste à ta remarque :

    "tant que la longueur du varchar() ne dépasse pas la limite qui provoquerait sa conversion automatique en champ TEXT (ou CLOB, ou … - suivant le RDBMS), ..."

    et que je précise une longueur de 100, sachant, maintenant, que les performances de ma BD ne seront pas peinalisées si je mets une donnée de 1 o dans ces champs.

    En espérant être clair et avoir bien tout compris...

  5. #5
    Membre Expert
    Homme Profil pro
    Inscrit en
    Septembre 2006
    Messages
    2 963
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Belgique

    Informations forums :
    Inscription : Septembre 2006
    Messages : 2 963
    Par défaut
    Citation Envoyé par olidau Voir le message
    Super, Merci.

    J'utiliserai donc un ou des champs en varchar(100), s'agissant de la limite max dont j'ai besoin.
    En parlant d'optimisation, je crois savoir que, à l'inverse, le problème se pose réellement pour les champs int2 et int4 :

    Je suppose que même dans PostgreSQL, il convient de faire le distingo entre les deux ?
    pour économiser 2 bytes par record ?

    faites vos calculs pour voir si en fonction de la taille espérée de la DB et de son hébergement… cela a un intérêt…

  6. #6
    Membre averti
    Profil pro
    Inscrit en
    Mai 2009
    Messages
    38
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Mai 2009
    Messages : 38
    Par défaut
    Non, ce n'est pas une question de coût de stockage.
    C'est pour augmenter la rapidité de traitement sur ces champs.
    J'imagine que faire des calculs sur des champs de 2 o (smallint) est deux fois plus rapide que sur des champs integer de 4 o.
    (Dans la mesure évidente où les info stockées se contentent de la portée d'un smallint).

  7. #7
    Membre Expert
    Homme Profil pro
    Inscrit en
    Septembre 2006
    Messages
    2 963
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Belgique

    Informations forums :
    Inscription : Septembre 2006
    Messages : 2 963
    Par défaut
    Citation Envoyé par olidau Voir le message
    Non, ce n'est pas une question de coût de stockage.
    C'est pour augmenter la rapidité de traitement sur ces champs.
    J'imagine que faire des calculs sur des champs de 2 o (smallint) est deux fois plus rapide que sur des champs integer de 4 o.
    (Dans la mesure évidente où les info stockées se contentent de la portée d'un smallint).
    …on est en 2009… pas en 1980…

  8. #8
    Rédacteur

    Avatar de SQLpro
    Homme Profil pro
    Expert bases de données / SQL / MS SQL Server / Postgresql
    Inscrit en
    Mai 2002
    Messages
    21 997
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Var (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Expert bases de données / SQL / MS SQL Server / Postgresql
    Secteur : Conseil

    Informations forums :
    Inscription : Mai 2002
    Messages : 21 997
    Billets dans le blog
    6
    Par défaut
    Contrairement à ce qui vous a été dit....
    Citation Envoyé par olidau Voir le message
    Non, ce n'est pas une question de coût de stockage.
    C'est pour augmenter la rapidité de traitement sur ces champs.
    J'imagine que faire des calculs sur des champs de 2 o (smallint) est deux fois plus rapide que sur des champs integer de 4 o.
    (Dans la mesure évidente où les info stockées se contentent de la portée d'un smallint).
    Un octets plus petit que la taille du mot du processeur oblige à effectuer une vérification logique de non overflow dans tous les calculs. C'est donc pénalisant (mais faiblement) par rapport à un entier qui est de la longueur exacte du mot du proc et pour lequel le calcul d'overflow est en logique micro câblée.
    Maintenant en terme de volume et aussi contrirement à ce que l'on vous a dit, plus le volume de donner à scruter est faible et plus les SCAN et dans une moindre mesure les SEEK seront rapides. En sus, la RAM n'étant généralement pas extensible, utiliser un type le plus petit possible permet de mettre en cache plus de données...

    Bien évidemment tout impacte les performances à des degrés divers et même en 2009 !

    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...
    * * * * * Expertise SQL Server : http://mssqlserver.fr/ * * * * *

  9. #9
    Membre averti
    Profil pro
    Inscrit en
    Mai 2009
    Messages
    38
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Mai 2009
    Messages : 38
    Par défaut
    Mouai...
    En tout cas, merci pour toutes ces info qui m'ont permis d'avancer.

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

Discussions similaires

  1. [Kylix] PostgreSql via ODBC
    Par doykati dans le forum EDI
    Réponses: 3
    Dernier message: 08/02/2007, 10h10
  2. [PostgreSQL] DATE to VARCHAR
    Par wwave dans le forum Langage SQL
    Réponses: 4
    Dernier message: 27/07/2006, 14h56
  3. [PostgreSQL] VARCHAR(2) to INT
    Par wwave dans le forum Langage SQL
    Réponses: 3
    Dernier message: 27/07/2006, 13h52
  4. Réponses: 4
    Dernier message: 28/09/2002, 00h00
  5. Réponses: 2
    Dernier message: 30/05/2002, 08h54

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