Si los documentos XML que se almacenarán son siempre inferiores a 64 KiB (que es, AFAIK, el límite de VARCHAR), ¿qué ventajas y desventajas tienen los tipos de columnas VARCHAR y TEXT que se utilizarán para esta tarea?¿Cuáles son las ventajas y desventajas de usar VARCHAR frente a TEXT para almacenar documentos XML pequeños en MySQL?
Los siguientes extractos se extrajeron de los documentos de MySQL correspondientes a string types.
"Una cadena de longitud variable .M representa la longitud máxima de columna en caracteres.El rango de M es de 0 a 65.535. La longitud máxima efectiva de un VARCHAR está sujeta al tamaño máximo de fila (65.535 bytes, que se comparte entre todas las columnas) y el conjunto de caracteres utilizado. Por ejemplo, los caracteres utf8 pueden requerir hasta tres bytes por carácter, por lo que una columna VARCHAR que use el conjunto de caracteres utf8 puede declararse como un máximo de 21,844 caracteres. Consulte la Sección E.10.4 , "Tabla Column-Count y Row-Size Limits".
MySQL almacena los valores de VARCHAR como un prefijo de longitud de uno o dos bytes más los datos. El prefijo de longitud indica el número de bytes en el valor. utiliza un byte de longitud si los valores no requieren más de 255 bytes, dos bytes de longitud si v los alores pueden requerir más de 255 bytes ".
Y la TEXT extracto:
"una columna de texto con una longitud máxima de 65.535 (216 - 1) caracteres La longitud máxima efectiva es menor si el valor contiene caracteres de varios bytes Cada valor de texto se almacena.. utilizando un prefijo de longitud de dos bytes que indica el número de bytes en el valor
Se puede otorgar una longitud M opcional para este tipo. Si esto se hace, MySQL crea la columna como el tipo de TEXTO más pequeño lo suficientemente grande como para contener valores M caracteres de largo ".
Parece que tanto el texto como el varchar son iguales en la superficie, ya que tienen la misma capacidad de almacenamiento para cadenas, pero después de algunas investigaciones adicionales, encontré el siguiente thread, que indica que MySQL maneja ambas columnas de manera diferente al tratar con índices y crear tablas temporales, que afectan el rendimiento de la consulta.
Si no tiene previsto realizar ninguna consulta con los datos que está almacenando, le sugiero que considere una solución NoSQL como MongoDB.
No está actualizado con MySQL pero el tipo de datos TEXT se ha vuelto obsoleto en SQL Server a favor de VARCHAR (MAX). Algunos de los inconvenientes del tipo de datos TEXTO en el que no se podía indexar, se almacenaba fuera de la página y no se podía buscar con una condición LIKE. –
¿Estás seguro de que "obsoleto" @lieven? ¿No hay casos en que encaja mejor que VARCHAR? En mi caso particular, voy a configurar el texto una vez y obtenerlo de vez en cuando (con una consulta separada, sin combinación, buscando un campo por una clave mucho más simple), probablemente sin necesidad de actualizarlo ni analizarlo alguna vez. – Ivan
Tenga en cuenta que estaba hablando específicamente sobre 'SQL Server' pero me gustaría * imaginar * MySQL siguiendo la misma ruta algún día. No tome esto como un consejo general, tengo curiosidad sobre lo que la comunidad tiene que decir al respecto y espero que alguien con experiencia se presente. –