sql-server-2008 - tipo - texto sql server
varchar(max) en todas partes? (7)
Hay otra razón para evitar el uso de varchar (max) en todas las columnas. Por el mismo motivo, utilizamos restricciones de verificación (para evitar llenar tablas con basura causada por software errante o entradas de usuario), quisiéramos protegernos contra cualquier proceso defectuoso que agregue mucha más información de la prevista. Por ejemplo, si alguien o algo intenta agregar 3.000 bytes en un campo de la Ciudad, sabríamos con certeza que algo anda mal y querríamos detener el proceso en seco para depurarlo en el punto más temprano posible. También sabríamos que un nombre de ciudad de 3000 bytes no podría ser válido y podría arruinar los informes y tal si intentásemos usarlo.
¿Hay algún problema con hacer que todas sus columnas de cadena Sql Server 2008 varchar (max)? Mis tamaños de cadena permitidos son gestionados por la aplicación. La base de datos solo debe persistir con lo que le doy. ¿Tomaré un golpe de rendimiento declarando que todas las columnas de cadenas sean de tipo varchar (max) en Sql Server 2008, sin importar el tamaño de los datos que realmente entren en ellas?
Hice la pregunta similar antes. obtuve algunas respuestas interesantes compruébalo here Hubo un sitio que tenía a un tipo hablando sobre el detrimento de usar columnas anchas, sin embargo, si tus datos son limitados en la aplicación, mi prueba lo desaprobó. El hecho de que no puedas crear índices en las columnas significa que no los usaría todo el tiempo (personalmente no los usaría mucho, pero soy un poco purista en ese sentido). Sin embargo, si sabes que no hay mucho almacenado en ellos, no creo que sean tan malos. Si realiza una ordenación en columnas de un conjunto de registros con un varchar (máximo) en él (o cualquier columna amplia que sea char o varchar), entonces podría sufrir penalizaciones de rendimiento. estos podrían resolverse (si es necesario) por índices, pero no puede poner índices en varchar (max). Si desea probar sus columnas en el futuro, ¿por qué no simplemente ponerlas en algo razonable? por ejemplo, una columna de nombre de 255 caracteres en lugar de máxima ... esa cosa.
Idealmente, solo debe permitir lo que necesita. Es decir, si está seguro de que una columna en particular (por ejemplo, una columna de nombre de usuario) nunca tendrá más de 20 caracteres, usar un VARCHAR (20) frente a un VARCHAR (MAX) permite que la base de datos optimice las consultas y las estructuras de datos.
Desde MSDN: http://msdn.microsoft.com/en-us/library/ms176089.aspx
Variable-length, non-Unicode character data. n can be a value from 1 through 8,000. max indicates that the maximum storage size is 2^31-1 bytes.
¿Realmente vas a estar cerca de 2 ^ 31-1 bytes para estas columnas?
Los índices no pueden tener más de 900 bytes de ancho para uno. Entonces probablemente nunca puedas crear un índice. Si sus datos son menos de 900 bytes, use varchar (900).
Este es un inconveniente: porque da
- muy mal rendimiento de búsqueda
- sin restricciones únicas
Para esta pregunta específicamente algunos puntos que no veo mencionados.
- En 2005/2008/2008 R2, si se incluye una columna LOB en un índice, esto bloqueará las reconstrucciones de índices en línea.
- En 2012, se levantó la restricción de reconstrucción del índice en línea, pero las columnas LOB no pueden participar en la nueva funcionalidad Agregar columnas NOT NULL como una operación en línea .
- Los bloqueos se pueden sacar más tiempo en las filas que contienen columnas de este tipo de datos. ( more )
Un par de otras razones están cubiertas en mi respuesta sobre por qué no varchar(8000) todas partes .
- Sus consultas pueden terminar solicitando grandes concesiones de memoria no justificadas por el tamaño de los datos.
- En la tabla con desencadenantes, puede evitar una optimización donde no se agregan las etiquetas de control de versiones.
Simon Sabin escribió una publicación sobre esto hace algún tiempo. No tengo tiempo para tomarlo ahora, pero debes buscarlo, porque él llega a la conclusión de que no debes usar varchar (max) de forma predeterminada.
Editado: Simon tiene algunas publicaciones sobre varchar (max). Los enlaces en los comentarios a continuación muestran esto bastante bien. Creo que el más significativo es http://sqlblogcasts.com/blogs/simons/archive/2009/07/11/String-concatenation-with-max-types-stops-plan-caching.aspx , que habla sobre el efecto de varchar (max) en el almacenamiento en caché del plan. El principio general es tener cuidado. Si no necesita que sea máximo, entonces no use max - si necesita más de 8000 caracteres, entonces seguro ... vaya por ello.
Al usar VARCHAR(MAX) básicamente le está diciendo a SQL Server que "almacene los valores en este campo como se ve mejor", SQL Server entonces elegirá si almacenar valores como un VARCHAR regular o como un LOB (objeto grande). En general, si los valores almacenados son de menos de 8,000 bytes SQL Server tratará los valores como un tipo VARCHAR regular.
Si los valores almacenados son demasiado grandes, se permite que la columna salga de la página en las páginas LOB, exactamente como lo hacen para otros tipos de LOB ( text , ntext e image ); si esto sucede, se requieren lecturas de página adicionales para leer el datos almacenados en las páginas adicionales (es decir, hay un rendimiento penatly), sin embargo, esto solo ocurre si los valores almacenados son demasiado grandes .
De hecho, en SQL Server 2008 o posterior, los datos pueden desbordarse en páginas adicionales incluso con los tipos de datos de longitud fija (por ejemplo, VARCHAR(3,000) ); sin embargo, estas páginas se denominan páginas de datos de desbordamiento de filas y se tratan de forma ligeramente diferente.
Versión corta: desde una perspectiva de almacenamiento no hay desventaja de utilizar VARCHAR(MAX) sobre VARCHAR(N) para algunos N
(Tenga en cuenta que esto también se aplica a los otros tipos de campo de longitud variable NVARCHAR y VARBINARY )