8768 sujets

Développement web côté serveur, CMS

Bonjour à tous
Depuis ... très longtemps ... je ne travaille plus dans un environnement COBOL, où il était indispensable de définir la longueur des champs, résultant du reste le plus souvent à des enregistrements contenant un nombre énorme d'espaces.

Ma base de données comprend actuellement 9 tables (non compris les tables "pma_" créées par le SGBD-R), chacune ayant une dizaine de champs, la plupart étant du texte. Le nombre de lignes par table est au plus de 250.
Je ne pense pas nécessaire de chercher à réduire la taille des champs, du moins pour la plupart, pour des raisons de taille disque occupée, par contre j'essaie de définir de "bonnes pratiques" concernant la longueur des champs numériques d'une part, textes d'autre part.

Ma question: quelles sont les bonnes pratiques en ce qui concerne la définition des types de champs ?

Pourriez vous me donner des conseils, en particulier pour les champs contenant du texte ?
Pour l'instant ce sont des varchar() et j'ai défini des longueurs 16, 32, 64, ... en fonction de ce que ces champs sont sensés contenir. Quid de "text" et ses petits frères ? Je me sens un peu parti à l'aveuglette.

Merci de vos conseils.
Modérateur
Bonjour,

Si tu n'as vraiment aucune idée de la taille des textes, utilise text, sinon varchar (varchar ayant une taille limite que tu peux choisir comme tu veux, ça peut par exemple t'éviter des catastrophes sans avoir besoin de tester la taille de ce que l'utilisateur a saisi).

Il y a aussi d'autres critères à considérer, mais dans un premier temps, tu peux les oublier.

Amicalement,
Hello Papy !

La différence entre un champ de type varchar ou text c’est essentiellement une question de performance. Utilise text uniquement pour stocker des très longues chaînes de caractères (une description ou le contenu d’un article par exemple). Car contrairement au champ de type varchar, un champ de type text ne peut pas être indexé.

Pour le reste tu fais juste, essaie de définir une longueur qui correspond à peu près à ce qui est attendu. Mais c’est pas vraiment le plus important.

Selon moi, il vaut mieux s’attarder longuement sur la conception de ton modèle relationnel, car il influence grandement l’efficacité des requêtes par la suite. Et là, des bonnes pratiques il y en a vraiment. Rien que dans le nommage de tes champs et tables.
Merci Anymah
Je n'ai pas trop de problème avec le schéma de la base, car en fait elle existe depuis une vingtaine d'années sous une autre forme, à base de feuilles Excel, et dès cette époque j'avais prévu que ça passerait en SQL un jour ou l'autre... sauf que je ne l'avais pas fait.
Je profite de cette refonte pour faire "au propre" des modifications que je n'avais pas faites pour ne pas tout chambouler, par exemple une "table des adresses" commune aux adresses des personnes et à celles des lieux, des choses de ce genre.
Pour l'instant tout va bien... comme disait le type qui tombait d'un gratte ciel en passant devant les fenêtres du 20ème étage.. Smiley cligne
PapyJP a écrit :
Pour l'instant tout va bien... comme disait le type qui tombait d'un gratte ciel en passant devant les fenêtres du 20ème étage.. Smiley cligne


C’est l’histoire d’un homme qui tombe d’un immeuble de 50 étages. Le mec, au fur et à mesure de sa chute, il se répète sans cesse pour se rassurer : « Jusqu’ici tout va bien... Jusqu’ici tout va bien... Jusqu’ici tout va bien. » Mais l’important, c’est pas la chute. C’est l’atterrissage.

La Haine, Hubert.