Moui, mais dans les faits, quand les données d'une ligne dépassent une certaine taille, Postgre crée à côté une table "TOAST", et ne stocke dans l'enregistrement de la table de données que le pointeur vers le bon enregistrement dans la table TOAST.
Du coup, garder un bon contrôle de la taille maximum d'un enregistrement reste utile. Et c'est plus facile avec varchar(n) qu'avec varchar.
Par ailleurs, quand tu bosses chez un éditeur, Postgre n'est peut-être qu'un des SGBDR que tu dois supporter. Et donc, tu veux pas nécessairement t'amuser à dire "alors, je fais un varchar(30) sur MSSQL, MySql, mais un varchar tout court sur Postgre".
Les esprits chagrins me diront "oui, mais sur Oracle de toute façon tu vas faire un varchar2(30)", mais il me semble que même Oracle a fini par prendre une bonne décision et dire que "OK, varchar et varchar2, c'est finalement pareil". Avec le bémol que ça fait 15 ans qu'ils disent "faites gaffe, on va finir par s'en servir pour faire autre chose".
Concernant la limite à 4000 caractères sur Oracle, a priori on peut la pousser (via un paramètre d'init) à 32767 d'après la doc, mais j'ai jamais essayé.
En tout cas, j'ai été vraiment très surpris de ce paragraphe sur varchar vs varchar(n), et ça me donne à réfléchir. Notamment sur le point qu'ils lèvent sur "potentielle non utilisation d'index si le paramètre a été reçu sous forme de varchar alors que la colonne est un char(n)". A mon sens c'est un bug qu'ils devraient corriger.
Egalement, j'avais pas conscience que "SERIAL" ne devrait plus être utilisé.
Au final, une très bonne lecture, même si je suis pas d'accord avec tout.
[^] # Re: varchar(n)
Posté par Dring . En réponse au journal PostgreSQL : ne faites pas ça !. Évalué à 6.
Moui, mais dans les faits, quand les données d'une ligne dépassent une certaine taille, Postgre crée à côté une table "TOAST", et ne stocke dans l'enregistrement de la table de données que le pointeur vers le bon enregistrement dans la table TOAST.
Du coup, garder un bon contrôle de la taille maximum d'un enregistrement reste utile. Et c'est plus facile avec varchar(n) qu'avec varchar.
Par ailleurs, quand tu bosses chez un éditeur, Postgre n'est peut-être qu'un des SGBDR que tu dois supporter. Et donc, tu veux pas nécessairement t'amuser à dire "alors, je fais un varchar(30) sur MSSQL, MySql, mais un varchar tout court sur Postgre".
Les esprits chagrins me diront "oui, mais sur Oracle de toute façon tu vas faire un varchar2(30)", mais il me semble que même Oracle a fini par prendre une bonne décision et dire que "OK, varchar et varchar2, c'est finalement pareil". Avec le bémol que ça fait 15 ans qu'ils disent "faites gaffe, on va finir par s'en servir pour faire autre chose".
Concernant la limite à 4000 caractères sur Oracle, a priori on peut la pousser (via un paramètre d'init) à 32767 d'après la doc, mais j'ai jamais essayé.
En tout cas, j'ai été vraiment très surpris de ce paragraphe sur varchar vs varchar(n), et ça me donne à réfléchir. Notamment sur le point qu'ils lèvent sur "potentielle non utilisation d'index si le paramètre a été reçu sous forme de varchar alors que la colonne est un char(n)". A mon sens c'est un bug qu'ils devraient corriger.
Egalement, j'avais pas conscience que "SERIAL" ne devrait plus être utilisé.
Au final, une très bonne lecture, même si je suis pas d'accord avec tout.