Discussion :

[budtucker]

Bonjour,

Je conçois actuellement une BDD Postgre. On m'impose de ne pas utiliser des VarChar puisque (et je le confirme) le type TEXT se resize automatiquement, il est énorme (1Go) et il ne prend pas plus de mémoire. D'un point de vue conceptuel, je trouve ça anormal puisque je souhaite avoir un ID d'une table de 20 caractères. Je trouverais ça plus "normal" d'avoir un champs VARCHAR(20). Cependant, dans le cas d'une évolution du soft, en laissant en TEXT, on n’aura pas besoin de retoucher à la base même si on augmente l'ID. Je confirme que la taille de la table deviendra très conséquente (plusieurs millers d'occurences) en l'espace de quelques mois.

Ma question est : Sans parler conception, mais plutôt optimisation, est ce que le choix d'un type TEXT est identique, plus approprié ou moins approprié qu'un type VARCHAR ???

A++

[JeitEmgie]

Bonjour,

Je conçois actuellement une BDD Postgre. On m'impose de ne pas utiliser des VarChar puisque (et je le confirme) le type TEXT se resize automatiquement, il est énorme (1Go) et il ne prend pas plus de mémoire. D'un point de vue conceptuel, je trouve ça anormal puisque je souhaite avoir un ID d'une table de 20 caractères. Je trouverais ça plus "normal" d'avoir un champs VARCHAR(20). Cependant, dans le cas d'une évolution du soft, en laissant en TEXT, on n’aura pas besoin de retoucher à la base même si on augmente l'ID. Je confirme que la taille de la table deviendra très conséquente (plusieurs millers d'occurences) en l'espace de quelques mois.

Ma question est : Sans parler conception, mais plutôt optimisation, est ce que le choix d'un type TEXT est identique, plus approprié ou moins approprié qu'un type VARCHAR ???

A++

VARCHAR est standard SQL, et non TEXT…

si un jour la DB doit être migrée vers un autre SGBD, en utilisant TEXT vous perdrez peut-être une portabilité qui est triviale avec VARCHAR…

le fait de ne pas spécifier de longueur max en utilisant TEXT, ne permet pas d'automatiser le check de longueur des champs dans une UI est se basant sur les méta informations du schéma… autrement dit : utiliser TEXT au lieu de VARCHAR ne va pas aider un éventuel outil RAD…

(NB: varchar sans paramètre de longueur semble avoir une longueur max de 10 Mb)

[budtucker]

Ok,

Merci pour les infos. Je suis ok pour les problème de check. Mais d'un point de vus perf, il n'y a pas de différence ? En fait, je me bat pour faire accepter le VARCHAR à la place du Text. Non pas parceque il y a des contraintes quelconque, mais parce que d'un point de vue conceptuel, c'est pas du tout bon.

Par exemple, je ne vais pas utiliser un type REAL pour stocker des entiers. C'est sans interêt. Mais on me l'impose donc, je suis contrains d'utiliser des TEXT.

A+

[JeitEmgie]

Ok,

Merci pour les infos. Je suis ok pour les problème de check. Mais d'un point de vus perf, il n'y a pas de différence ? En fait, je me bat pour faire accepter le VARCHAR à la place du Text. Non pas parceque il y a des contraintes quelconque, mais parce que d'un point de vue conceptuel, c'est pas du tout bon.

Par exemple, je ne vais pas utiliser un type REAL pour stocker des entiers. C'est sans interêt. Mais on me l'impose donc, je suis contrains d'utiliser des TEXT.

A+

tant que les champs concernés ne doivent pas être indexés, cela ne doit pas changer grand chose…

[GrandFather]

Bonjour,

Après avoir épluché la doc, je n'ai trouvé aucune différence de performances qui plaiderait en faveur de VARCHAR plutôt que de TEXT. Le choix de l'un ou l'autre se fera donc essentiellement en fonction de qu'a dit JeitEmgie concernant la conformité SQL.

(NB: varchar sans paramètre de longueur semble avoir une longueur max de 10 Mb)

Sauf erreur de ma part, varchar sans paramètre a la même limite que TEXT et CHAR, à savoir 1 Gb.

[JeitEmgie]

Sauf erreur de ma part, varchar sans paramètre a la même limite que TEXT et CHAR, à savoir 1 Gb.

la limite est bien 1Gb dans toutes les version récentes…

mais attention CHAR sans paramètre == CHAR(1)…
donc sans paramètre CHAR != VARCHAR…