exagerando el tamaño del campo en el diseño de la base de datos

Tengo algunos campos para mis tablas que son cadenas y en este momento, la mayoría del tamaño del campo tiene límites de caracteres bastante altos. Por ejemplo, 100 caracteres para el nombre de la calle. ¿Hay una penalización por usar un campo de gran tamaño? Si cambio el límite a 30 caracteres para este campo, por ejemplo, ¿habrá una ganancia de rendimiento o una eficiencia con el tamaño? Habría unos 50 campos que podrían ser candidatos para la contracción.

Gracias por sus sugerencias

Si está hablando varchary nvarcharluego no, no hay penalización por permitir una mayor longitud de campo.

Sin embargo, algunas advertencias a tener en cuenta:

• Hay una sobrecarga de 2 bytes por fila para los campos de longitud variable (por campo). Si tiene un campo muy corto, puede tener más sentido usar a CHAR. Varchar(2)por ejemplo, en realidad usa entre 2 y 4 bytes por fila, mientras que CHAR(2)siempre usa 2.
• Los campos muy largos no se pueden indexar. La longitud máxima para todos los campos en un conjunto de claves de índice es de 900 bytes.
• Si permite más datos de los esperados, eventualmente obtendrá resultados inesperados. Si permite 100 caracteres para un nombre de calle, en algún momento es probable que ingresen otros datos en ese campo sin que usted lo sepa (por ejemplo, la dirección completa). Si lo tuviera del tamaño adecuado, es probable que obtenga un error al insertarlo.
• Permitir filas muy anchas podría provocar divisiones de página y fragmentación. Si tiene una fila de más de 8k, deberá dividirse en varias páginas de datos. Muchos de estos realmente pueden dañar el rendimiento. Más estrecho en general es más eficiente.

Si quiere decir, "¿Hay una penalización por declarar el tamaño del campo más grande que cualquier valor que realmente esté almacenado en él?", Entonces, siempre que se declare varchar, la respuesta es no. Todos los motores SQL DB que conozco almacenan solo el número de caracteres realmente dados en los datos (más un valor de longitud). Entonces, si define el campo como varchar (100) pero solo almacena 10 caracteres en él, solo ocupará 10 caracteres en el disco (más 2 bytes más o menos para la longitud). En caso de duda, rutinariamente hago que mis campos varchar sean ridículamente grandes.

Si quiere decir, "¿Hay una penalización por almacenar campos de caracteres largos", la respuesta es sí. El espacio en disco hoy es barato, pero no es gratuito, por lo que no debe desperdiciarlo sin ningún motivo. Probablemente más importante, lleva tiempo leer los datos del disco, por lo que cuanto más largos sean los campos de datos, más lento se volverá el programa. Si el campo está indexado, esto realmente puede ralentizar sus recuperaciones, ya que cada lectura tendrá que comparar el valor clave con este gran campo largo.

Tenga en cuenta que si le da al usuario un gran campo de entrada de datos, lo usará, tarde o temprano.

Dicho todo esto, me equivocaría del lado de demasiado grande en lugar de demasiado pequeño. El espacio en disco es lo suficientemente barato como para no obligar a los usuarios a inventar abreviaturas sobre la marcha porque no pueden ajustar los datos reales en el campo disponible. El sistema en el que estoy trabajando hoy tiene un campo de descripción del producto que es demasiado pequeño para muchos de los nombres reales de nuestros productos, por lo que los usuarios deben abreviar. Y, por supuesto, cada usuario abrevia de manera diferente, por lo que tenemos veinte formas diferentes de decir lo mismo.

Cualquiera que afirme que no hay penalidad por declarar un tamaño de campo mayor que el que realmente se almacenará en la tabla es incorrecto. El tamaño real de los datos (más esa sobrecarga de 2 bytes) es lo que realmente se almacena, pero es la definición de columna que se utiliza para determinar la estimación en lo que respecta al plan de ejecución. Entonces, si bien declarar un varchar (1000) para almacenar un valor de 10 caracteres solo consumirá 12 caracteres de espacio en disco, las estimaciones del plan de ejecución serán mucho menos eficientes y sesgarán negativamente los resultados, tanto para la cantidad de memoria para otorgar la operación como para si la operación se puede realizar únicamente en la memoria o si también requerirá espacio en la unidad tempdb. Puede hacer que su columna varchar (1000), pero el motor no sabe que todos sus valores almacenados son realmente menores que varchar (10),

La verificación de longitud de campo es algo que obtienes 'gratis', lo que significa que no tienes que usar una CHECKrestricción para hacer lo mismo. Y no desea valores de datos sobredimensionados cuando, por ejemplo, tiene que cargar sus datos a otra base de datos que ha limitado el mismo elemento de datos a 35 caracteres en línea con la dirección estándar internacional.