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

260

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

  • 1
    Это зависит от того, что вам нужно, индексация, уникальность?
  • 1
    Я ожидал довольно простой ответ здесь, но был довольно удивлен ответами, охватывающими пункты, которые я не рассматривал. Очень интересное чтение, которое я добавил в свой учебный аккаунт.
Показать ещё 1 комментарий
Теги:
database

10 ответов

252
Лучший ответ
  • 12
    Хороший ответ, но лично я бы ограничил длину. В зависимости от проекта вы можете ограничить количество принятых URL. Кто использует URL длиннее 200?
  • 2
    Им лучше придумать тип данных uri, который «понимает» структуру uri, чтобы индексирование и поиск выполнялись эффективно, как это сделал oracle ... подождите, mysql теперь является oracle's ... download.oracle.com/docs/ кд / B10464_05 / web.904 / b12099 / ...
Показать ещё 7 комментариев
31

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

  • 0
    как насчет сопоставления?
14

varchar (max) для SQLServer2005

varchar (65535) для MySQL 5.0.3 и более поздних версий

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

  • 1
    Является ли в вашем фрагменте max волшебным спецификатором ANSI SQL для увеличения размера VARCHAR по мере необходимости, или это просто мета-переменная для примера?
  • 1
    Это синтаксис SQL2005. Редактирование , ,
Показать ещё 2 комментария
7

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

VARCHAR(512) CHARACTER SET 'ascii' COLLATE 'ascii_general_ci' NOT NULL
  • 4
    разве UTF-8 не использует больше места, когда это только нужно?
6

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

Используйте VARCHAR с maxlength >= 2,083 как micahwittman, если:

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

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

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

Это действительно зависит от вашего варианта использования (см. ниже), но сохранение в качестве 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 для слишком длинных ссылок.
  • 8
    Если вы предоставляете встроенное средство сокращения URL, вам все равно нужно будет хранить полный URL-адрес в базе данных где-нибудь, чтобы он работал? :-)
  • 0
    Конечно; но я сомневаюсь, что большинство людей написали бы свое собственное сокращение. С тех пор, как я написал это, я узнал, что существует множество API для сокращения URL (здесь перечислены 71: programmableweb.com/news/… ), так что вы можете автоматизировать процесс, даже не создавая свой собственный. Конечно, это зависит от знаний и согласия пользователя.
4

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

3

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

1

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

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

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

  • 0
    varchar (max) - это синтаксис SQLServer, не подходящий для MySQL (как в первоначальном вопросе). Более того, это не означает varchar (65535) поскольку 65535 - это максимальное количество символов ASCII в строке в mysql, поэтому оно зависит также от других полей и набора символов.
0

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

Ещё вопросы

Сообщество Overcoder
Наверх
Меню