Loại trường cơ sở dữ liệu tốt nhất cho một URL


352

Tôi cần lưu trữ một url trong bảng MySQL. Cách thực hành tốt nhất để xác định trường sẽ giữ URL có độ dài không xác định là gì?


1
Nó phụ thuộc vào những gì bạn cần, lập chỉ mục, đơn nhất?
Thomas Decaux

2
Tôi đã mong đợi một câu trả lời khá đơn giản ở đây nhưng khá ngạc nhiên với các câu trả lời bao gồm các mục tôi đã không xem xét. Đọc rất thú vị mà tôi đã thêm vào tài khoản giáo dục của tôi.
HPWD

1
Chỉ cần đi với TEXTloại và bỏ qua đọc tất cả các câu trả lời dưới đây. Cuối cùng, đó là những gì hầu hết trong số họ đề nghị. :) Tất nhiên, nếu bạn cần lập chỉ mục hoặc tính duy nhất, hãy chọn VARCHAR, vì TEXTkhông thể được lập chỉ mục một cách dễ dàng .
Alexanderar

Câu trả lời:


324
  1. Độ dài URL tối đa của mẫu số chung thấp nhất trong số các trình duyệt web phổ biến: 2.083 (Internet Explorer)

  2. http://dev.mysql.com/doc/refman/5.0/en/char.html
    Giá trị trong các cột VARCHAR là các chuỗi có độ dài thay đổi. Độ dài có thể được chỉ định làm giá trị từ 0 đến 255 trước MySQL 5.0.3 và 0 đến 65.535 trong 5.0.3 và các phiên bản mới hơn. Độ dài tối đa hiệu quả của VARCHAR trong MySQL 5.0.3 trở lên phải tuân theo kích thước hàng tối đa (65.535 byte, được chia sẻ giữa tất cả các cột) và bộ ký tự được sử dụng.

  3. Vì vậy, ...
    <MySQL 5.0.3 sử dụng TEXT
    hoặc
    > = MySQL 5.0.3 sử dụng VARCHAR (2083)


14
Câu trả lời tốt, nhưng cá nhân tôi sẽ giới hạn chiều dài. Tùy thuộc vào dự án mà bạn có thể muốn giới hạn các url được chấp nhận. Ai sử dụng url longet hơn 200?
John

2
Họ tốt hơn nên đưa ra một kiểu dữ liệu uri "hiểu" cấu trúc của uri để việc lập chỉ mục và tìm kiếm được thực hiện một cách hiệu quả, giống như oracle đã ... chờ đợi, mysql bây giờ là ... download.oracle.com/docs/ cd / B10464_05 / web.904 / b12099 / Sự
redben

80
Câu trả lời này là một chút sai lệch. Lưu ý rằng "Mẫu số chung thấp nhất" ở đây là vô nghĩa, bạn muốn sử dụng số cao nhất mà trình duyệt hoặc máy chủ sẽ chấp nhận (không phù hợp và có thể thay đổi). Như liên kết của bạn nói: " ... thông số kỹ thuật của giao thức HTTP không chỉ định bất kỳ độ dài tối đa nào ... ", vì vậy đừng bận tâm với điều đó VARCHAR(2083), chỉ cần sử dụng TEXT.
Wesley Murch

4
Ví dụ, cũng từ liên kết của bạn: " Sau 65.536 ký tự, thanh vị trí không còn hiển thị URL trong Windows Firefox 1.5.x. Tuy nhiên, các URL dài hơn sẽ hoạt động. Tôi đã dừng kiểm tra sau 100.000 ký tự. "
Wesley Murch

1
Tài nguyên boutell.com rơi ra khỏi mạng. Dưới đây là một tham chiếu đến nó trong một cuốn sách O'Reilly quét: books.google.ca/...
micahwittman

33

VARCHAR(512)(hoặc tương tự) nên là đủ. Tuy nhiên, vì bạn không thực sự biết độ dài tối đa của các URL được đề cập, tôi có thể chỉ cần truy cập trực tiếp vào TEXT. Điều nguy hiểm với điều này tất nhiên là mất hiệu quả do CLOBs chậm hơn nhiều so với kiểu dữ liệu chuỗi đơn giản như VARCHAR.


Còn đối chiếu thì sao?
kommradHomer 30/03/2017

16

varchar(max) cho SQLServer2005

varchar(65535) cho MySQL 5.0.3 trở lên

Điều này sẽ phân bổ lưu trữ khi cần và không ảnh hưởng đến hiệu suất.


1
Trong đoạn trích của bạn, là maxmột công cụ xác định ANSI SQL kỳ diệu để tăng kích thước VARCHAR khi cần thiết hay nó chỉ là một biến meta vì lợi ích của ví dụ?
Daniel Spiewak

4
Trong MySQL, rất có thể bạn không thể có một varchar lớn như vậy trừ khi đó là cột duy nhất trong bảng.
caron

1
@Daniel Spiewak: "Sự khác biệt cơ bản giữa TEXT và VARCHAR (MAX) là loại văn bản sẽ luôn lưu trữ dữ liệu trong một blob trong khi loại VARCHAR (MAX) sẽ cố lưu trữ dữ liệu trực tiếp trong hàng trừ khi vượt quá 8k hạn chế và tại thời điểm đó, nó lưu trữ nó trong một đốm màu. " stackoverflow.com/questions/834788/ Mạnh Nhưng câu hỏi là về MySQL, vì vậy điều này không thực sự phù hợp ở đây.
Stijn Bollen

9

Bạn sẽ muốn chọn giữa một cột văn bản hoặc VARCHAR dựa trên tần suất sử dụng URL và liệu bạn có thực sự cần độ dài không bị ràng buộc hay không.

Sử dụng VARCHAR với maxlength> = 2.083 như micahwittman đề xuất nếu:

  1. Bạn sẽ sử dụng rất nhiều URL cho mỗi truy vấn (không giống như các cột văn bản, VARCHAR được lưu trữ nội tuyến với hàng)
  2. Bạn khá chắc chắn rằng một URL sẽ không bao giờ vượt quá giới hạn hàng là 65.535 byte.

Sử dụng văn bản nếu:

  1. URL thực sự có thể phá vỡ giới hạn hàng 65,535 byte
  2. Các truy vấn của bạn sẽ không chọn hoặc cập nhật một loạt các URL cùng một lúc (hoặc rất thường xuyên). Điều này là do các cột TEXT chỉ giữ một con trỏ nội tuyến và các truy cập ngẫu nhiên liên quan đến việc truy xuất dữ liệu được tham chiếu có thể gây đau đớn.

9

Bạn nên sử dụng VARCHAR với mã hóa ký tự ASCII. Các URL được mã hóa phần trăm và các tên miền quốc tế sử dụng Punycode để ASCII đủ để lưu trữ chúng. Điều này sẽ sử dụng ít không gian hơn nhiều so với UTF8.

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

5
UTF-8 không sử dụng nhiều không gian hơn khi chỉ có?
kommradHomer 30/03/2017

7

Điều này thực sự phụ thuộc vào trường hợp sử dụng của bạn (xem bên dưới), nhưng việc lưu trữ TEXTcó vấn đề về hiệu suất và VARCHARâm thanh lớn như quá mức cần thiết cho hầu hết các trường hợp.

Cách tiếp cận của tôi: sử dụng VARCHARđộ dài lớn nhưng không hợp lý , chẳng hạn như VARCHAR(500)hoặc, và khuyến khích người dùng cần URL lớn hơn để sử dụng trình rút ngắn URL, chẳng hạn như safe.mn.

Cách tiếp cận Twitter: Để có một UX thực sự tốt, hãy cung cấp trình rút ngắn URL tự động cho URL quá dài và lưu trữ "phiên bản hiển thị" của liên kết dưới dạng một đoạn URL có dấu chấm lửng ở cuối. (Ví dụ: http://stackoverflow.com/q/219569/1235702sẽ được hiển thị dưới dạng stackoverflow.com/q/21956...và sẽ liên kết đến một URL rút ngắn http://ex.ampl/e1234)

Ghi chú và hãy cẩn thận

  • Rõ ràng, cách tiếp cận Twitter đẹp hơn, nhưng đối với nhu cầu của ứng dụng của tôi, khuyến nghị sử dụng công cụ rút ngắn URL là đủ.
  • Công cụ rút ngắn URL có nhược điểm của chúng, chẳng hạn như mối quan tâm bảo mật. Trong trường hợp của tôi, đó không phải là một rủi ro lớn vì URL không công khai và không được sử dụng nhiều; tuy nhiên, điều này rõ ràng sẽ không hiệu quả với tất cả mọi người. safe.mn dường như chặn rất nhiều thư rác và URL lừa đảo, nhưng tôi vẫn khuyên bạn nên thận trọng.
  • Hãy chắc chắn lưu ý rằng bạn không nên ép buộc người dùng của mình sử dụng trình rút ngắn URL. Đối với hầu hết các trường hợp (ít nhất là cho nhu cầu của ứng dụng của tôi), 500 ký tự là quá đủ cho hầu hết người dùng sẽ sử dụng nó cho mục đích gì. Chỉ sử dụng / đề xuất một trình rút ngắn URL cho các liên kết quá dài.

10
Nếu bạn đang cung cấp một trình rút ngắn url tích hợp, bạn sẽ vẫn không cần lưu trữ url có độ dài đầy đủ trong cơ sở dữ liệu ở đâu đó để nó hoạt động chứ? :-)
Neil Neyman

2
Tất nhiên; nhưng tôi nghi ngờ hầu hết mọi người sẽ viết rút gọn của riêng họ. Kể từ khi viết bài này, tôi đã biết rằng có rất nhiều API rút ngắn URL ngoài kia (71 được liệt kê ở đây: programizableweb.com/news/iêu ), vì vậy bạn có thể tự động hóa quy trình mà không cần tự viết. Tất nhiên nó vẫn phụ thuộc vào kiến ​​thức và sự đồng ý của người dùng.
brokethebuildagain



1

Hầu hết các máy chủ web có giới hạn độ dài URL (đó là lý do tại sao có mã lỗi cho "URI quá dài"), có nghĩa là có kích thước trên thực tế. Tìm giới hạn độ dài mặc định cho các máy chủ web phổ biến nhất và sử dụng giới hạn lớn nhất của chúng làm kích thước tối đa của trường; nó là quá đủ


1

Bạn nên sử dụng varchar (max) có nghĩa là (về kích thước) varchar (65535). Điều này thậm chí sẽ lưu trữ các địa chỉ web lớn hơn của bạn và cũng sẽ tiết kiệm không gian của bạn.

Công cụ xác định tối đa mở rộng khả năng lưu trữ của các kiểu dữ liệu varchar, nvarchar và varbinary. varchar (max), nvarchar (max) và varbinary (max) được gọi chung là các kiểu dữ liệu giá trị lớn. Bạn có thể sử dụng các loại dữ liệu có giá trị lớn để lưu trữ tối đa 2 ^ 31-1 byte dữ liệu.

Xem bài viết này trên TechNet về việc sử dụng Kiểu dữ liệu giá trị lớn


varchar (max)là cú pháp SQLServer, không phù hợp với MySQL (như trong câu hỏi ban đầu). Hơn nữa, điều đó không có nghĩa là varchar (65535)vì 65535 là số ký tự ASCII tối đa liên tiếp trong mysql, do đó, nó cũng phụ thuộc vào các trường khác và vào bộ ký tự.
furins
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.