Лучший тип поля базы данных для URL

Мне нужно хранить URL в таблице MySQL. Каков наилучший способ определения поля, которое будет содержать URL с неопределенной длиной?

1. Максимальная длина URL в общем знаменателе среди популярных веб-браузеров: 2 083 (Internet Explorer)

2. http://dev.mysql.com/doc/refman/5.0/en/char.html
   Значения в столбцах VARCHAR являются строками переменной длины. Длина может быть указана как значение от 0 до 255 до MySQL 5.0.3 и от 0 до 65 535 в 5.0.3 и более поздних версиях. Эффективная максимальная длина VARCHAR в MySQL 5.0.3 и более поздних версиях зависит от максимального размера строки (65 535 байт, который распределяется между всеми столбцами) и используемого набора символов.

3. Итак ...
   <MySQL 5.0.3 использует TEXT
   или
   > = MySQL 5.0.3 использует VARCHAR (2083)

VARCHAR(512)(или аналогичный) должно быть достаточно. Однако, поскольку вы на самом деле не знаете максимальную длину URL-адресов, о которых идет речь, я могу просто перейти непосредственно к TEXT. Опасность в этом заключается, конечно, в потере эффективности из-за CLOBтого, что она намного медленнее, чем простой тип данных типа строкиVARCHAR .

varchar(max) для SQLServer2005

varchar(65535) для MySQL 5.0.3 и выше

Это будет выделять память по мере необходимости и не должно влиять на производительность.

Вы хотите , чтобы выбрать между TEXT или столбца VARCHAR на основе , как часто будет использоваться URL и ли вы на самом деле нужно длину , чтобы быть несвязанным.

Использование VARCHAR с MAXLENGTH> = 2083 , как micahwittman предлагается , если:

1. Вы будете использовать много URL для каждого запроса (в отличие от столбцов TEXT, VARCHAR хранятся в строке вместе со строкой)
2. Вы уверены, что URL никогда не превысит ограничение строки в 65 535 байт.

Используйте ТЕКСТ, если:

1. URL действительно может нарушить ограничение строки в 65 535 байт
2. Ваши запросы не будут выбирать или обновлять несколько URL-адресов сразу (или очень часто). Это связано с тем, что столбцы TEXT просто содержат встроенный указатель, и случайный доступ, связанный с получением ссылочных данных, может быть болезненным.

Вы должны использовать VARCHAR с кодировкой символов ASCII. URL-адреса кодируются в процентах, а в международных доменных именах используется punycode, поэтому для их хранения достаточно ASCII. Это займет гораздо меньше места, чем UTF8.

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

Это действительно зависит от вашего варианта использования (см. Ниже), но хранение в нем TEXTимеет проблемы с производительностью, и в VARCHARбольшинстве случаев это звучит как избыточное количество.

Мой подход: используйте щедрую, но не слишком большую VARCHARдлину, такую ​​как VARCHAR(500)или около того, и поощряйте пользователей, которым нужен больший URL, использовать сокращение URL, такое как safe.mn.

Подход Twitter: для действительно приятного UX обеспечьте автоматическое сокращение URL-адресов для слишком длинных URL-адресов и сохраните «отображаемую версию» ссылки в виде фрагмента URL-адреса с эллипсами в конце. (Пример: http://stackoverflow.com/q/219569/1235702будет отображаться как stackoverflow.com/q/21956...и будет ссылаться на сокращенный URL http://ex.ampl/e1234)

Примечания и предостережения

• Очевидно, что подход Twitter более приятен, но для нужд моего приложения было рекомендовано рекомендовать сокращение URL.
• Укороченные URL-адреса имеют свои недостатки, такие как проблемы безопасности. В моем случае это не огромный риск, потому что URL-адреса не являются общедоступными и не используются; однако, это очевидно не будет работать для всех. Safe.mn блокирует множество спамовых и фишинговых URL, но я все равно рекомендую осторожность.
• Обязательно обратите внимание, что вы не должны заставлять своих пользователей использовать сокращатель URL. В большинстве случаев (по крайней мере, для нужд моего приложения) 500 символов слишком много для того, для чего его будет использовать большинство пользователей. Используйте / рекомендуйте сокращение URL для слишком длинных ссылок.

Большинство браузеров позволяют вам помещать очень большие объемы данных в URL-адрес, и поэтому многие вещи заканчивают тем, что создают очень большие URL-адреса, поэтому, если вы говорите о чем-то большем, чем доменная часть URL-адреса, вам нужно будет использовать столбец TEXT, так как VARCHAR / CHAR ограничены .

Я не знаю о других браузерах, но IE7 имеет ограничение в 2083 символа для операций HTTP GET . Если у других браузеров нет более низких лимитов, я не понимаю, зачем вам нужно больше символов, чем 2083.

Большинство веб-серверов имеют ограничение длины URL-адреса (поэтому существует код ошибки для «слишком длинного URI»), что означает практический верхний размер. Найдите ограничение длины по умолчанию для самых популярных веб-серверов и используйте самый большой из них в качестве максимального размера поля; этого должно быть более чем достаточно.

Вам лучше использовать varchar (max), что (с точки зрения размера) означает varchar (65535). Это даже сохранит ваши большие веб-адреса и сэкономит ваше пространство.

Спецификатор max расширяет возможности хранения типов данных varchar, nvarchar и varbinary. varchar (max), nvarchar (max) и varbinary (max) вместе называются типами данных большого значения. Вы можете использовать большие типы данных для хранения до 2 ^ 31-1 байтов данных.

См. Эту статью на TechNet об использовании типов данных больших значений.