Meilleur type de champ de base de données pour une URL

J'ai besoin de stocker une URL dans une table MySQL. Quelle est la meilleure pratique pour définir un champ qui contiendra une URL d'une longueur indéterminée?

1. Longueur maximale de l'URL du plus petit dénominateur commun parmi les navigateurs Web populaires: 2 083 (Internet Explorer)

2. http://dev.mysql.com/doc/refman/5.0/en/char.html Les
   valeurs dans les colonnes VARCHAR sont des chaînes de longueur variable. La longueur peut être spécifiée sous la forme d'une valeur de 0 à 255 avant MySQL 5.0.3 et de 0 à 65 535 dans les versions 5.0.3 et ultérieures. La longueur maximale effective d'un VARCHAR dans MySQL 5.0.3 et versions ultérieures est soumise à la taille de ligne maximale (65 535 octets, partagée entre toutes les colonnes) et au jeu de caractères utilisé.

3. Donc ...
   <MySQL 5.0.3 utilise TEXT
   ou
   > = MySQL 5.0.3 utilise VARCHAR (2083)

VARCHAR(512)(ou similaire) devrait être suffisant. Cependant, comme vous ne connaissez pas vraiment la longueur maximale des URL en question, je pourrais aller directement à TEXT. Le danger avec ceci est bien sûr la perte d'efficacité due au fait que CLOBs est beaucoup plus lent qu'un simple type de données de type chaîne VARCHAR.

varchar(max) pour SQLServer2005

varchar(65535) pour MySQL 5.0.3 et versions ultérieures

Cela allouera du stockage en fonction des besoins et ne devrait pas affecter les performances.

Vous voudrez choisir entre une colonne TEXT ou VARCHAR en fonction de la fréquence à laquelle l'URL sera utilisée et si vous avez réellement besoin que la longueur soit non liée.

Utilisez VARCHAR avec maxlength> = 2083 comme micahwittman suggéré si:

1. Vous utiliserez beaucoup d'URL par requête (contrairement aux colonnes TEXT, les VARCHARs sont stockés en ligne avec la ligne)
2. Vous êtes quasiment sûr qu'une URL ne dépassera jamais la limite de ligne de 65 535 octets.

Utilisez TEXT si:

1. L'URL pourrait vraiment dépasser la limite de ligne de 65 535 octets
2. Vos requêtes ne sélectionneront ni ne mettront à jour un groupe d'URL à la fois (ou très souvent). En effet, les colonnes TEXT contiennent simplement un pointeur en ligne et les accès aléatoires impliqués dans la récupération des données référencées peuvent être pénibles.

Vous devez utiliser un VARCHAR avec un codage de caractères ASCII. Les URL sont codées en pourcentage et les noms de domaine internationaux utilisent punycode, donc ASCII est suffisant pour les stocker. Cela utilisera beaucoup moins d'espace que UTF8.

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

Cela dépend vraiment de votre cas d'utilisation (voir ci-dessous), mais le stockage, tout comme TEXTles problèmes de performances, et un énorme VARCHARbruit de surpuissance dans la plupart des cas.

Mon approche: utilisez une VARCHARlongueur généreuse, mais pas déraisonnablement grande , telle VARCHAR(500)ou telle, et encouragez les utilisateurs qui ont besoin d'une URL plus grande à utiliser un raccourcisseur d'URL tel que safe.mn.

L'approche Twitter: pour une expérience utilisateur vraiment agréable, fournissez un raccourcisseur d'URL automatique pour les URL trop longues et stockez la "version d'affichage" du lien comme un extrait de l'URL avec des ellipses à la fin. (Exemple: http://stackoverflow.com/q/219569/1235702serait affiché comme stackoverflow.com/q/21956...et serait lié à une URL raccourciehttp://ex.ampl/e1234 )

Notes et mises en garde

• De toute évidence, l'approche Twitter est plus agréable, mais pour les besoins de mon application, recommander un raccourcisseur d'URL était suffisant.
• Les raccourcisseurs d'URL ont leurs inconvénients, tels que des problèmes de sécurité. Dans mon cas, ce n'est pas un risque énorme car les URL ne sont pas publiques et peu utilisées; cependant, cela ne fonctionnera évidemment pas pour tout le monde. safe.mn semble bloquer un grand nombre d'URL de spam et de phishing, mais je recommanderais tout de même la prudence.
• N'oubliez pas de ne pas forcer vos utilisateurs à utiliser un raccourcisseur d'URL. Dans la plupart des cas (au moins pour les besoins de mon application), 500 caractères sont trop suffisants pour ce que la plupart des utilisateurs l'utiliseront. N'utilisez / recommandez un raccourcisseur d'URL que pour les liens trop longs.

La plupart des navigateurs vous permettent de mettre de très grandes quantités de données dans une URL et donc beaucoup de choses finissent par créer de très grandes URL, donc si vous parlez de plus que la partie domaine d'une URL, vous devrez utiliser une colonne TEXT depuis le VARCHAR / CHAR sont limités .

Je ne connais pas les autres navigateurs, mais IE7 a une limite de 2083 caractères pour les opérations HTTP GET . À moins que d'autres navigateurs aient des limites inférieures, je ne vois pas pourquoi vous auriez besoin de plus de caractères que 2083.

La plupart des serveurs Web ont une limite de longueur d'URL (c'est pourquoi il existe un code d'erreur pour "URI trop long"), ce qui signifie qu'il existe une taille supérieure pratique. Trouvez la limite de longueur par défaut pour les serveurs Web les plus populaires et utilisez le plus grand d'entre eux comme taille maximale du champ; cela devrait être plus que suffisant.

Vous feriez mieux d'utiliser varchar (max) ce qui (en termes de taille) signifie varchar (65535). Cela stockera même vos adresses Web plus importantes et économisera également votre espace.

Le spécificateur max étend les capacités de stockage des types de données varchar, nvarchar et varbinary. varchar (max), nvarchar (max) et varbinary (max) sont collectivement appelés types de données de grande valeur. Vous pouvez utiliser les types de données de grande valeur pour stocker jusqu'à 2 ^ 31-1 octets de données.

Consultez cet article sur TechNet sur l'utilisation de types de données de grande valeur