El mejor tipo de campo de base de datos para una URL


352

Necesito almacenar una url en una tabla MySQL. ¿Cuál es la mejor práctica para definir un campo que contendrá una URL con una longitud indeterminada?


1
¿Depende de lo que necesita, indexación, unicidad?
Thomas Decaux el

2
Esperaba una respuesta bastante sencilla aquí, pero me sorprendió bastante las respuestas que cubrían los elementos que no había considerado. Lectura muy interesante que he agregado a mi cuenta educativa.
HPWD

1
Simplemente vaya con el TEXTtipo y omita leer todas estas respuestas a continuación. Al final, eso es lo que la mayoría de ellos sugieren. :) Por supuesto, si necesita indexación o unicidad, busque VARCHAR, ya TEXTque no puede indexarse tan fácilmente .
Aleksandar

Respuestas:


324
  1. Mínimo común denominador longitud máxima de URL entre navegadores web populares: 2,083 (Internet Explorer)

  2. http://dev.mysql.com/doc/refman/5.0/en/char.html Los
    valores en las columnas VARCHAR son cadenas de longitud variable. La longitud se puede especificar como un valor de 0 a 255 antes de MySQL 5.0.3 y de 0 a 65.535 en 5.0.3 y versiones posteriores. La longitud máxima efectiva de un VARCHAR en MySQL 5.0.3 y posterior está sujeta al tamaño máximo de fila (65.535 bytes, que se comparte entre todas las columnas) y al conjunto de caracteres utilizado.

  3. Entonces ...
    <MySQL 5.0.3 usa TEXT
    o
    > = MySQL 5.0.3 usa VARCHAR (2083)


14
Buena respuesta, pero personalmente limitaría la longitud. Dependiendo del proyecto, es posible que desee limitar las URL aceptadas. ¿Quién usa url más de 200?
John

2
Será mejor que inventen un tipo de datos uri que "entienda" la estructura de uri para que la indexación y la búsqueda se realicen de manera eficiente, como lo hizo Oracle ... espere, mysql ahora es Oracle ... download.oracle.com/docs/ cd / B10464_05 / web.904 / b12099 /…
redben

80
Esta respuesta es un poco engañosa. Tenga en cuenta que el "mínimo común denominador" aquí no tiene sentido, desea utilizar el número más alto que aceptará un navegador o servidor (que no es coherente y está sujeto a cambios). Como dice su enlace: " ... la especificación del protocolo HTTP no especifica ninguna longitud máxima ... ", así que no se moleste con eso VARCHAR(2083), solo use TEXT.
Wesley Murch

44
Ejemplo, también desde su enlace: " Después de 65,536 caracteres, la barra de ubicación ya no muestra la URL en Windows Firefox 1.5.x. Sin embargo, las URL más largas funcionarán. Dejé de probar después de 100,000 caracteres " .
Wesley Murch

1
El recurso boutell.com se cayó de la red. Aquí hay una referencia en un libro escaneado de O'Reilly: books.google.ca/…
micahwittman

33

VARCHAR(512)(o similar) debería ser suficiente. Sin embargo, dado que realmente no conoce la longitud máxima de las URL en cuestión, podría ir directamente a TEXT. El peligro con esto es, por supuesto, la pérdida de eficiencia debido a que CLOBs es mucho más lento que un tipo de datos de cadena simple VARCHAR.


¿Qué pasa con la colación?
kommradHomer

16

varchar(max) para SQLServer2005

varchar(65535) para MySQL 5.0.3 y posterior

Esto asignará el almacenamiento según sea necesario y no debería afectar el rendimiento.


1
En su fragmento, ¿hay maxun especificador mágico ANSI SQL para aumentar el tamaño de VARCHAR según sea necesario, o es solo una meta-variable por el bien de ejemplo?
Daniel Spiewak

44
En MySQL, lo más probable es que no pueda tener un varchar tan grande a menos que sea la única columna en la tabla.
carson

1
@Daniel Spiewak: "La diferencia básica entre TEXT y VARCHAR (MAX) es que un tipo TEXT siempre almacenará los datos en un blob mientras que el tipo VARCHAR (MAX) intentará almacenar los datos directamente en la fila a menos que exceda los 8k limitación y en ese punto lo almacena en un blob ". stackoverflow.com/questions/834788/… Pero la pregunta era sobre MySQL, por lo que esto no es realmente relevante aquí.
Stijn Bollen

9

Deberá elegir entre una columna TEXTO o VARCHAR en función de la frecuencia con la que se utilizará la URL y si realmente necesita que la longitud esté sin consolidar.

Use VARCHAR con maxlength> = 2,083 como micahwittman sugirió si:

  1. Utilizará muchas URL por consulta (a diferencia de las columnas TEXT, los VARCHAR se almacenan en línea con la fila)
  2. Está bastante seguro de que una URL nunca excederá el límite de fila de 65.535 bytes.

Use TEXTO si:

  1. La URL realmente podría romper el límite de filas de 65.535 bytes
  2. Sus consultas no seleccionarán ni actualizarán un montón de URL a la vez (o muy a menudo). Esto se debe a que las columnas TEXT solo mantienen un puntero en línea, y los accesos aleatorios involucrados en la recuperación de los datos referenciados pueden ser dolorosos.

9

Debe usar un VARCHAR con una codificación de caracteres ASCII. Las URL están codificadas en porcentaje y los nombres de dominio internacionales usan punycode, por lo que ASCII es suficiente para almacenarlos. Esto usará mucho menos espacio que UTF8.

VARCHAR(512) CHARACTER SET 'ascii' COLLATE 'ascii_general_ci' NOT NULL

55
¿No utiliza UTF-8 más espacio cuando solo tiene que hacerlo?
kommradHomer

7

Esto realmente depende de su caso de uso (ver más abajo), pero el almacenamiento ya que TEXTtiene problemas de rendimiento, y un gran VARCHARsonido parece excesivo en la mayoría de los casos.

Mi enfoque: usar una VARCHARlongitud generosa, pero no irrazonablemente grande , como más VARCHAR(500)o menos, y alentar a los usuarios que necesitan una URL más grande a usar un acortador de URL como safe.mn.

El enfoque de Twitter: para una experiencia de usuario realmente agradable, proporcione un acortador automático de URL para URL demasiado largas y almacene la "versión para mostrar" del enlace como un fragmento de la URL con puntos suspensivos al final. (Ejemplo: http://stackoverflow.com/q/219569/1235702se mostrará como stackoverflow.com/q/21956...y se vinculará a una URL acortada http://ex.ampl/e1234)

Notas y advertencias

  • Obviamente, el enfoque de Twitter es mejor, pero para las necesidades de mi aplicación, recomendar un acortador de URL fue suficiente.
  • Los acortadores de URL tienen sus inconvenientes, como problemas de seguridad. En mi caso, no es un gran riesgo porque las URL no son públicas y no se usan mucho; Sin embargo, esto obviamente no funcionará para todos. Parece que safe.mn bloquea una gran cantidad de URL de spam y phishing, pero aún así recomendaría precaución.
  • Asegúrese de tener en cuenta que no debe obligar a sus usuarios a usar un acortador de URL. Para la mayoría de los casos (al menos para las necesidades de mi aplicación), 500 caracteres son demasiado suficientes para lo que la mayoría de los usuarios la usarán. Solo use / recomiende un acortador de URL para enlaces demasiado largos.

10
Si está proporcionando un acortador de URL incorporado, ¿no necesitará almacenar la URL completa en una base de datos en algún lugar para que funcione? :-)
Neil Neyman

2
Por supuesto; pero dudo que la mayoría de la gente escriba su propio acortador. Desde que escribí esto, aprendí que hay muchas API de acortamiento de URL (71 se enumeran aquí: programmableweb.com/news/… ), por lo que puede automatizar el proceso sin siquiera escribir el suyo. Todavía depende del conocimiento y el consentimiento del usuario, por supuesto.
brokethebuildagain



1

La mayoría de los servidores web tienen un límite de longitud de URL (por lo que hay un código de error para "URI demasiado largo"), lo que significa que hay un tamaño superior práctico. Encuentre el límite de longitud predeterminado para los servidores web más populares y use el más grande de ellos como el tamaño máximo del campo; Debería ser más que suficiente.


1

Es mejor usar varchar (max) que (en términos de tamaño) significa varchar (65535). Esto incluso almacenará sus direcciones web más grandes y también ahorrará su espacio.

El especificador max expande las capacidades de almacenamiento de los tipos de datos varchar, nvarchar y varbinary. varchar (max), nvarchar (max) y varbinary (max) se denominan colectivamente tipos de datos de gran valor. Puede usar los tipos de datos de gran valor para almacenar hasta 2 ^ 31-1 bytes de datos.

Consulte este artículo en TechNet sobre el uso de tipos de datos de gran valor


varchar (max)es la sintaxis de SQLServer, no adecuada para MySQL (como en la pregunta original). Además, no significa que varchar (65535)ya que 65535 es el número máximo de caracteres ASCII seguidos en mysql, por lo que depende también de los otros campos y del conjunto de caracteres.
Furins
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.