Décider de la longueur des champs du fichier de formes?

Dans mon travail, j'ai hérité de plusieurs fichiers de formes provenant de MapInfo que j'apporte dans un nouveau projet dans QGIS. J'ai la possibilité de modifier les noms des colonnes, d'ajouter et de soustraire des colonnes et parce qu'il n'y a pas trop de données en elles, je peux recommencer et ajuster les longueurs de champ aussi.

Je remarque que certaines des longueurs de champ sont beaucoup plus grandes qu'elles ne devraient l'être et je me souviens de la création de bases de données antérieures il y a 20 ans, ou plus, qu'il est préférable de garder les longueurs de champ pour ne pas être plus longues qu'elles ne devraient l'être économiser sur «l'espace», pour améliorer l'efficacité.

Est-ce toujours souhaitable ou la longueur du champ n'a plus d'importance?

qgis fields-attributes length

— Martin Hügi
source

Cela dépend du format que vous utilisez.

— bugmenot123

La longueur du champ doit probablement être maintenue à "pas plus qu'elle ne doit l'être" par définition, vous n'avez besoin de rien de plus. Bien sûr, cela dépend de ce que vous capturez pour déterminer la longueur dont vous avez "besoin".

— DMusketeer

OMI, la meilleure pratique la plus importante consiste à cesser d'utiliser des fichiers de formes si possible.

— alphabetasoup

La réponse dépend du format des données. Les fichiers dBase-III +, qui sont utilisés dans les fichiers de formes pour les attributs, ont une largeur fixe. Par conséquent, la définition d'une colonne FIPS de 254 largeur utilise 254 octets. Pire encore, dBase a une largeur d'enregistrement maximale de 4000 octets, donc les 249 gaspillés sur un champ de cinq caractères ne sont pas disponibles pour les autres champs (dont il y a un maximum de 100 ou 255, selon qui met en œuvre la norme). Des limites s'appliquent également à la taille totale du fichier dBase (2 Go), qui pourrait être approchée par 536 Ko d'enregistrements à la largeur maximale, alors que 5,36 m d'enregistrements seraient disponibles à une largeur de 400 octets.

Il existe une autre raison de limiter la largeur de champ: la qualité des données. Si un désignateur ne peut légalement contenir que deux caractères, mais que vous le définissez avec dix, vous augmentez la possibilité d'avoir une valeur invalide aux doigts gras acceptée par le fichier de données.

D'un autre côté, si vous ne fournissez que la largeur nécessaire et obtenez des données internationales au format UTF-8, vous risquez de vous retrouver à court d'espace lorsqu'un caractère peut utiliser 2 à 6 octets.

Ainsi, pour les champs de chaîne de base de données (qui incluent la géodatabase fichier), qui sont généralement terminés et ne gaspillent donc pas d'espace de ligne, la flexibilité est une option, mais pour les formats à largeur fixe, les anciennes règles s'appliquent toujours.

— Vince
source

Merci pour les réponses. Je ne suis pas sûr de bien comprendre la réponse de Vince car je ne sais pas grand-chose sur les différentes structures de base de données, mais je comprends l'essentiel. Je pense que ma principale considération sera alors l'intégrité des données et la mise en place de rien de plus long que nécessaire - ce qui semble évident maintenant - merci

— Martin Hügi

Les principaux outils pour remercier ceux qui répondent à votre question sont de voter et de marquer la réponse. Si vous n'êtes pas clair sur quelque chose, demandez. L'idée ici est de construire de bonnes réponses.

— Vince

@Vince a bien répondu à cela, il n'y a qu'une autre petite raison pour laquelle j'ajouterais: clarifier l'intention. Lorsqu'un champ nommé "état" n'a que 2 caractères, il est évident que le champ est censé contenir l'abréviation standard pour un état. Cependant, si vous définissez ce champ sur 50 ou 200 caractères, il peut être interprété comme contenant le nom complet de l'état. Cela est lié à la qualité globale des données.

— RustProof Labs

Suivi - Après 18 mois, tout cela a beaucoup plus de sens maintenant - excellente réponse

— Martin Hügi