De acuerdo con las especificaciones de DNS la longitud máxima del nombre de dominio es:
255 * 3 =765 <767 (Apenas :-) )
Sin embargo, tenga en cuenta que cada componente solo puede tener 63 caracteres.
Por lo tanto, sugeriría cortar la URL en los bits del componente.
Probablemente esto sería adecuado:
- indicador de protocolo ["http" -> 0 ] (almacene "http" como 0, "https" como 1, etc.)
- subdominio ["foo"] (255 - 63 =192 caracteres:podría restar 2 más porque el tld mínimo tiene 2 caracteres)
- dominio ["ejemplo"], (63 caracteres)
- tld ["com"] (4 caracteres para manejar "info" tld)
- ruta [ "a/realmente/larga/ruta"] (tanto como quieras -almacenar en una tabla separada )
- queryparameters ["with=lots&of=query¶meters=that&goes=on&forever&and=ever" ] (almacenar en una tabla de clave/valor separada )
- El número de puerto/autenticación que rara vez se usa puede estar en una tabla con clave separada si realmente se necesita.
Esto le brinda algunas ventajas agradables:
- El índice está solo en las partes de la URL en las que necesita buscar (¡índice más pequeño!)
- las consultas se pueden limitar a las distintas partes de la URL (busque cada URL en el dominio de Facebook, por ejemplo)
- cualquier URL que tenga un subdominio/dominio demasiado largo es falso
- parámetros de consulta fáciles de descartar.
- búsqueda fácil de hacer que no distingue entre mayúsculas y minúsculas por nombre de dominio/tld
- deseche la sintaxis azúcar ( "://" después del protocolo, "." entre subdominio/dominio, dominio/tld, "/" entre tld y ruta, "?" antes de la consulta, "&" "=" en el consulta)
- Evita el principal problema de la tabla dispersa. La mayoría de las URL no tendrán parámetros de consulta ni rutas largas. Si estos campos están en una tabla separada, su tabla principal no tendrá el impacto de tamaño. Al realizar consultas, caben más registros en la memoria, por lo tanto, un rendimiento de consulta más rápido.
- (más ventajas aquí).