2010-07-21 27 views
11

En un MDB de acceso-Ms, ¿ahorrará espacio en disco para limitar el tamaño de los campos de texto de longitud variable?Ms-Access: cualquier necesidad de tener un tamaño pequeño para campos de texto de longitud variable

por ejemplo. Si tengo un campo Text de longitud variable del tamaño 20 y todos los valores reales del campo están bajo 10 caracteres, ¿estoy perdiendo espacio?

¿Sería mejor establecer el tamaño del campo en 10, o no hace ninguna diferencia?

+0

No está claro si realmente tiene acceso o si solo está utilizando un archivo MDB, pero si tiene acceso, le sugiero que aproveche esta práctica pequeña llamada ARCHIVO DE AYUDA. Puede que se sorprenda de lo que podría aprender al mirar allí. –

+0

@David: ¿Qué diferencia hace? La pregunta se aplicaría a ambos escenarios. Y no creo que este problema esté cubierto en el archivo de Ayuda. – CJ7

+0

¿Has mirado el archivo de ayuda tú mismo? Si no, échale un vistazo y luego vuelve con nosotros. –

Respuesta

8

Si tengo un campo de texto de longitud variable de tamaño 20 y todos los valores reales del campo son menores de 10 caracteres, estoy perdiendo el espacio?

¿Sería mejor para establecer el tamaño del campo a 10, o qué no hace ninguna diferencia?

Sería mejor establecer 10 como límite de tamaño de campo si los valores de más de 10 caracteres son inaceptables. Si está bien que un usuario ingrese valores entre 11 y 20 caracteres, deje el límite en 20. El uso de espacio en el disco no es un problema en esta situación.

+0

Incluso si el campo es parte de un PK? ¿No habría un impacto en el rendimiento y el tamaño en ese caso? –

+0

Quiero decir: Table Customers tiene una clave principal = CustId Text (50). El CustID nunca es mayor que 10 char. ¿El db será más rápido y más pequeño configurando el campo CustId como Texto (10)? –

+0

@iDevlop Dudo que haya una diferencia para el tamaño del índice porque no creo que el índice "rellene" los valores del campo hasta el ancho del campo permitido. No sé sobre el impacto en el rendimiento. – HansUp

3

Los campos se almacenan como longitud variable, y establecer así el tamaño como 255 o 10 no reducirá ni cambiará el tamaño del archivo de datos.

0

Creo que es una propiedad heredada de la parte posterior cuando la memoria era costosa.

Puede usarlo como método de validación de datos, es decir, si el campo contiene números de teléfono, al dar una longitud de 10 evitará que se ingresen números de teléfono internacionales y no válidos.

+0

¿No estaría la interfaz de usuario validando la entrada? – CJ7

+2

Si bien sería prudente recurrir a las herramientas que la interfaz de usuario proporciona para validar las entradas de los usuarios, el motor de la base de datos debería hacer cumplir tanto como sea posible la entrada de datos válidos. Elegir la longitud del campo es una de las herramientas a nivel del motor para hacerlo. –

+0

@David: la IU debería haber validado cualquier entrada antes de llegar al DB – CJ7

-4

La longitud del campo debe elegirse adecuadamente porque tiene un efecto sobre el rendimiento del índice y el almacenamiento, ya que los valores más largos crean más páginas de datos. Por supuesto, si los datos son reales, es decir, los valores reales deben ser tan largos, lo necesita. Por lo tanto, si tiene un campo de 50 caracteres y el valor más largo es de 10 caracteres, el índice no ocupará más espacio que si el campo tuviera 10 caracteres.

Pero elegir un límite apropiado ayuda con el diseño de formularios e informes: si hace que el campo sea demasiado largo, puede terminar con registros atípicos que no se muestran/imprimen correctamente. Por otro lado, no desea que sea demasiado corto para que los usuarios no puedan incluir datos normales en él. La longitud del campo es la forma más básica de validación de datos, porque usted está decidiendo cuál es el rango de valores apropiados para ese campo.

Mi principio básico es que escojo la longitud de campo más corta posible para los datos que tienen un formato regular (incluso si tiene excepciones ocasionales), pero soy generoso con los campos que no lo hacen.

+0

explique cómo afecta el almacenamiento. – CJ7

+0

Almacenamiento de índice específicamente: los índices "más amplios" ocupan más páginas de datos y se fragmentan más rápidamente, lo que reduce el rendimiento. Los índices más estrechos son más rápidos de buscar porque son menos datos. –

+0

cualquier referencia? Parece extraño que el espacio del índice esté relacionado con la definición de la columna y no con el uso real de la columna. – pascal

4

Aunque no se menciona explícitamente, creo que se está preguntando si existe alguna diferencia con respecto al almacenamiento de datos con el límite de cadenas de longitud variable: no habrá diferencia al usar límites mayores o menores. A partir de MSDN, la discusión de los tipos de datos de texto para el JET (El motor de base de Acceso)

En general, los campos de texto pueden tener hasta 255 caracteres, [...] Además, las partes no utilizadas de los campos de texto son no reservado en la memoria .

Cuestiones relacionadas