Decidir la longitud de los campos de shapefile?

En mi trabajo heredé varios shapefiles que se originan en MapInfo que estoy trayendo a un nuevo proyecto en QGIS. Tengo la oportunidad de cambiar los nombres de las columnas, sumar y restar columnas y, dado que todavía no hay demasiados datos, puedo comenzar de nuevo y ajustar las longitudes de los campos también.

Me doy cuenta de que algunas de las longitudes de campo son mucho más grandes de lo necesario y recuerdo de la creación de la base de datos anterior hace 20 años, más o menos, que es mejor mantener las longitudes de campo para que no sean más largas de lo necesario. Ahorre espacio para mejorar la eficiencia.

¿Sigue siendo deseable o ya no importa la longitud del campo?

qgis fields-attributes length

— Martin Hügi
fuente

Depende del formato que esté utilizando.

— bugmenot123

La longitud del campo probablemente debería mantenerse "no más de lo necesario", por definición, no necesita nada más. Por supuesto, depende de lo que esté capturando para determinar qué longitud "necesita".

— DMusketeer

En mi opinión, la mejor práctica más importante es dejar de usar shapefiles si es posible.

— alphabetasoup

La respuesta depende del formato de datos. Los archivos dBase-III +, que se usan en los archivos de forma de los atributos, tienen un ancho fijo, por lo que definir una columna FIPS para que tenga un ancho de texto de 254 usa 254 bytes. Peor aún, dBase tiene un ancho de registro máximo de 4000 bytes, por lo que los 249 desperdiciados en un campo de cinco caracteres no están disponibles para otros campos (de los cuales hay un máximo de 100 o 255, dependiendo de quién implemente el estándar). Los límites también se aplican al tamaño total del archivo dBase (2 Gb), al que se podría llegar con un registro de 536k con un ancho máximo, cuando los registros de 5.36m estarían disponibles con un ancho de 400 bytes.

Hay otra razón para limitar el ancho del campo: la calidad de los datos. Si un designador solo puede contener legalmente dos caracteres, pero lo define con diez, entonces aumenta la posibilidad de que el archivo de datos acepte un valor inválido con dedos gordos.

Por otro lado, si proporciona solo el ancho necesario y obtiene datos internacionales en formato UTF-8, es posible que tenga poco espacio cuando un personaje puede usar 2-6 bytes.

Por lo tanto, para los campos de cadena de la base de datos (que incluye la geodatabase de archivos), que generalmente se terminan y, por lo tanto, no desperdician espacio en las filas, la flexibilidad es una opción, pero para los formatos de ancho fijo, las reglas antiguas aún se aplican.

— Vince
fuente

Gracias por las respuestas No estoy seguro de entender completamente la respuesta de Vince, ya que no sé mucho sobre las diferentes estructuras de bases de datos, pero entiendo lo esencial. Creo que mi principal consideración será la integridad de los datos y no configurar nada más de lo necesario, lo que parece obvio ahora, gracias

— Martin Hügi

Las principales herramientas para agradecer a quienes responden su pregunta son votar y marcar la pregunta respondida. Si no tienes claro algo, pregunta. La idea aquí es construir buenas respuestas.

— Vince

@Vince respondió esto bien, solo hay una pequeña razón más que agregaría: aclarar la intención. Cuando un campo llamado "estado" tiene solo 2 caracteres, es obvio que se supone que el campo tiene la abreviatura estándar para un estado. Sin embargo, si hace que ese campo tenga 50 o 200 caracteres, puede interpretarse que contiene el nombre completo del estado. Esto se relaciona con la calidad general de los datos.

— RustProof Labs

Seguimiento - Después de 18 meses, todo esto tiene mucho más sentido ahora - gran respuesta

— Martin Hügi