Лучший тип поля базы данных для URL
Мне нужно сохранить URL-адрес в таблице MySQL. Как лучше всего определить поле, которое будет содержать URL-адрес неопределенной длины?
Я ожидал здесь довольно прямого ответа, но был весьма удивлен ответами, касающимися вопросов, которые я не рассматривал. Очень интересное чтение, которое я добавил в свой образовательный аккаунт.
Просто выберите тип TEXT и пропустите чтение всех этих ответов ниже. В конце концов, это то, что предлагает большинство из них. :) Конечно, если Вам нужна индексация или уникальность, выбирайте VARCHAR, так как TEXT не может быть проиндексирован это легко.
Ответы 10
VARCHAR(512) (или аналогичный) должно быть достаточно. Однако, поскольку вы действительно не знаете максимальную длину рассматриваемых URL-адресов, я мог бы просто перейти непосредственно к TEXT. Опасность здесь заключается, конечно, в потере эффективности из-за того, что CLOB намного медленнее, чем простой строковый тип данных, такой как VARCHAR.
как насчет сопоставления?
varchar(max) для SQLServer2005
varchar(65535) для MySQL 5.0.3 и новее
Это позволит выделить память по мере необходимости и не должно повлиять на производительность.
В вашем фрагменте max - это волшебный спецификатор ANSI SQL для увеличения размера VARCHAR по мере необходимости, или это просто метапеременная для примера?
В MySQL у вас, скорее всего, не может быть такой большой varchar, если только это не единственный столбец в таблице.
@Daniel Spiewak: "Основное различие между TEXT и VARCHAR (MAX) заключается в том, что тип TEXT всегда будет хранить данные в большом двоичном объекте, тогда как тип VARCHAR (MAX) будет пытаться хранить данные непосредственно в строке, если только он не превышает 8k ограничение, и в этот момент он сохраняет его в виде капли ". stackoverflow.com/questions/834788/… Но вопрос был о MySQL, так что здесь это не совсем актуально.
Большинство браузеров позволяют вам помещать очень большие объемы данных в URL, и, таким образом, многие вещи в конечном итоге создают очень большие URL-адреса, поэтому, если вы говорите о чем-либо, кроме доменной части URL-адреса, вам нужно будет использовать столбец TEXT, поскольку VARCHAR / CHAR ограничены.
Насчет других браузеров не знаю, но IE7 имеет ограничение на 2083 символа для операций HTTP GET.. Если в других браузерах не установлены более низкие ограничения, я не понимаю, зачем вам нужно больше 2083 символов.
Большинство веб-серверов имеют ограничение на длину URL-адреса (поэтому есть код ошибки «URI too long»), что означает, что существует практический верхний размер. Найдите ограничение длины по умолчанию для самых популярных веб-серверов и используйте самый большой из них в качестве максимального размера поля; этого должно быть более чем достаточно.
- Lowest common denominator max URL length among popular web browsers: 2,083 (Internet Explorer)
- http://dev.mysql.com/doc/refman/5.0/en/char.html
Values in VARCHAR columns are variable-length strings. The length can be specified as a value from 0 to 255 before MySQL 5.0.3, and 0 to 65,535 in 5.0.3 and later versions. The effective maximum length of a VARCHAR in MySQL 5.0.3 and later is subject to the maximum row size (65,535 bytes, which is shared among all columns) and the character set used.
- So ...
< MySQL 5.0.3 use TEXT
or
>= MySQL 5.0.3 use VARCHAR(2083)
Хороший ответ, но лично я бы ограничился длиной. В зависимости от проекта вы можете захотеть ограничить допустимые URL-адреса. Кто использует url длиннее 200?
Им лучше придумать тип данных uri, который "понимает" структуру uri, чтобы индексация и поиск выполнялись эффективно, как это сделал oracle ... подождите, mysql теперь принадлежит oracle ... download.oracle.com/docs/cd/B10464_05/web.904/b12099/…
Этот ответ немного вводит в заблуждение. Обратите внимание, что «наименьший общий знаменатель» здесь не имеет смысла, вы хотите использовать число самый высокий, которое примет браузер или сервер (который не является согласованным и может быть изменен). Как сказано в вашей ссылке: «... в спецификации протокола HTTP не указана максимальная длина ...», так что не беспокойтесь об этом VARCHAR(2083), просто используйте TEXT.
Пример, также из вашей ссылки: "После 65 536 символов в строке адреса больше не отображается URL-адрес в Windows Firefox 1.5.x. Однако более длинные URL-адреса будут работать. Я прекратил тестирование после 100 000 символов."
Что касается №3: обратите внимание, что если вы используете MySql и хотите установить значение по умолчанию, вы должны использовать VARCHAR (stackoverflow.com/questions/3466872/…)
@John Я сейчас храню Магнитные ссылки, некоторые из этих ссылок. 483 символа для одной из моих ссылок
Я использую MySQL 5.6.31, и я хотел бы сделать поле url уникальным ключом, тогда сервер говорит максимальная длина ключа 767 байт Итак, я решил установить его длину на 767. Кроме того, мне также нужно установить символ в ascii. Окончательный sql выглядит так: CREATE TABLE pages (id INT AUTO_INCREMENT NOT NULL, url VARCHAR(767) NOT NULL, UNIQUE INDEX UNIQ_2074E575F47645AE (url), PRIMARY KEY(id)) DEFAULT CHARACTER SET ascii COLLATE ascii_general_ci ENGINE = InnoDB
Я не уверен в кодировке по умолчанию, но я думаю, что установка набора символов в utf-8 лучше.
К вашему сведению - Asp.Net MVC [Display(Name = "My URL")] [Column(TypeName = "VARCHAR")] [StringLength(2083)] public string MyUrl { get; set; }
Ресурс boutell.com выпал из сети. Вот ссылка на это в отсканированной книге О'Рейли: books.google.ca/…
@WesleyMurch Я знаю, что это старая ветка, но все равно. Если вы используете SQL Server 2005 или новее, используйте varchar (MAX). Тип данных text устарел и не должен использоваться для новых разработок.
Вам лучше использовать varchar (макс.), что (с точки зрения размера) означает varchar (65535).
Это даже сохранит ваши большие веб-адреса и также сэкономит ваше место.
The max specifier expands the storage capabilities of the varchar, nvarchar, and varbinary data types. varchar(max), nvarchar(max), and varbinary(max) are collectively called large-value data types. You can use the large-value data types to store up to 2^31-1 bytes of data.
См. Раздел эта статья на сайте TechNet об использовании типов данных большого размера.
varchar (max) - это синтаксис SQLServer, не подходящий для MySQL (как в исходном вопросе). Кроме того, это не означает varchar (65535), поскольку 65535 - это максимальное количество символов ASCII в строке в mysql, поэтому оно также зависит от других полей и набора символов.Вы захотите выбрать между столбцом TEXT или VARCHAR на основе как часто URL будет использоваться, и нужно ли вам, чтобы длина на самом деле была несвязанной.
Используйте VARCHAR с максимальной длиной> = 2,083 в качестве Micahwittman, предложенного, если:
- Вы будете использовать много URL-адресов для каждого запроса (в отличие от столбцов TEXT, VARCHAR хранятся внутри строки)
- Вы почти уверены, что URL-адрес никогда не превысит ограничение на количество строк в 65 535 байт.
Используйте ТЕКСТ, если:
- URL-адрес действительно может превысить ограничение в 65535 байт.
- Ваши запросы не будут выбирать или обновлять сразу несколько URL-адресов (или очень часто). Это связано с тем, что столбцы TEXT просто содержат встроенный указатель, и случайный доступ, связанный с извлечением данных, на которые имеются ссылки, может быть болезненным.
Это действительно зависит от вашего варианта использования (см. Ниже), но хранение в формате 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-адрес где-нибудь в базе данных, чтобы он работал? :-)
Конечно; но я сомневаюсь, что большинство людей напишут свой собственный сокращатель. С тех пор, как я написал это, я узнал, что существует множество API-интерфейсов сокращения URL-адресов (здесь перечислены 71: programmableweb.com/news/…), поэтому вы можете автоматизировать процесс, даже не написав свой собственный. Конечно, это все еще зависит от знаний и согласия пользователя.
Вы должны использовать VARCHAR с кодировкой символов ASCII. URL-адреса закодированы в процентах, а в международных доменных именах используется punycode, поэтому для их хранения достаточно ASCII. Это займет гораздо меньше места, чем UTF8.
VARCHAR(512) CHARACTER SET 'ascii' COLLATE 'ascii_general_ci' NOT NULL
разве UTF-8 не использует больше места, когда это нужно?
Смотря что вам нужно, индексация, уникальность?