2010-07-30 27 views

Respuesta

3

La diferencia será insignificante en la mayoría de los casos. Concentre sus esfuerzos de diseño orientados al rendimiento en los lugares en los que marcará una diferencia real, como la composición de la mesa y el diseño del índice.

Ayuda a dividir el esfuerzo de diseño en dos capas: diseño lógico y diseño físico.
La mayor parte del esfuerzo orientado al rendimiento se encuentra en la segunda etapa, el diseño físico.

En diseño lógico, la flexibilidad supera el rendimiento. Excepto cuando no lo hace

+1

¡La flexibilidad casi nunca debe superar al rendimiento! Garantizo que el usuario desea un rendimiento superior a la flexibilidad, incluso cuando dicen que quieren flexibilidad. – HLGEM

1

apenas importa, ya que está utilizando 1 byte en ambos casos.

pero larga historia corta, varchar es de tamaño variable & char es de tamaño fijo. en grandes cantidades, esto puede hacer una diferencia en el espacio de almacenamiento y afectar el tiempo de cálculo.

En cuanto al rendimiento, utilice char si los datos van a ser de longitud fija. si es flexible con una longitud de datos variable, entonces use varchar.

+3

*** NO 1 byte en ambos casos! *** - por ejemplo - MYSQL v5.0 dice que los requisitos de almacenamiento varchar para varchar (M) requieren 'L + 1 bytes si los valores de columna requieren 0 - 255 bytes' (donde L representa la longitud real en bytes de un dado valor de cadena). Por lo tanto, estaría utilizando 1 byte para CHAR (1) y 2 bytes para VARCHAR (1). En ese caso, está usando un 100% MÁS de espacio de almacenamiento para esta columna. Esto puede o no ser un gran problema dependiendo de la situación de uso. Sin embargo, vale la pena señalar la diferencia en caso de que sea pertinente. (ver http://dev.mysql.com/doc/refman/5.0/en/storage-requirements.html) –

2

En lo que se refiere a Oracle ....

CHAR (2) siempre utilizará dos bytes/caracteres de almacenamiento. VARCHAR2 (2) solo puede usar uno. Entonces, el caso general es usar VARCHAR2 en lugar de CHAR.

En la práctica, no debería ver una diferencia en cuanto al rendimiento para una columna de un solo carácter.

Como nunca hay un beneficio de CHAR, siempre uso VARCHAR2.

+4

Sin embargo, el varchar tendrá que almacenar al menos un byte para la longitud de la cadena, por lo que nunca puedes tener menos de 1 byte – Gabe

0

Después de leer la descripción de MySQL de VARCHAR y CHAR es que si los datos siempre van a tener la misma longitud, entonces CHAR podría ahorrarle un byte de datos porque VARCHAR requiere el almacenamiento de un byte por separado de los datos reales para registrar cuánto tiempo son los datos. Sin embargo, si los datos no son de una longitud constante y estás pensando en consideraciones espaciales, tendría sentido usar VARCHAR porque CHAR siempre usará un byte para cada bit de la longitud declarada si hay algo en ese espacio. .

Al final, sin embargo, probablemente no marque una gran diferencia ya que la cantidad de datos involucrados es bastante pequeña.

Aquí es donde obtuve mi información: http://dev.mysql.com/doc/refman/5.0/en/char.html Si sigue el enlace, preste especial atención a la pequeña tabla, ya que da ejemplos de cómo se manejarían los datos con VARCHAR frente a CHAR.

3

En MS SQL VARCHAR (1) utiliza TRES bytes de almacenamiento y CHAR (1) usa un byte de almacenamiento.

CHAR (1) es más eficiente que VARCHAR (1) en el procesamiento y almacenamiento.

El punto "punto de equilibrio" en VARCHAR sería algo mayor a 3 caracteres si se usan datos de longitud variable.

Si usa una longitud fija, entonces CHAR siempre es más eficiente en dos bytes.

REF: http://msdn.microsoft.com/en-gb/library/ms176089.aspx