1. Trang chủ
  2. Câu hỏi và trả lời
  3. Loại trường cơ sở dữ liệu tốt nhất cho URL

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

2008-10-20 46 views

Trả lời

257

  1. Lowest common denominator max URL length among popular web browsers: 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à chuỗi chiều dài thay đổi. Độ dài có thể được xác định dưới dạng 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 sau. Độ dài tối đa hiệu dụng của VARCHAR trong MySQL 5.0.3 và sau đó phụ thuộc vào 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ậy ...
    < MySQL 5.0.3 sử dụng TEXT
    hoặc
    > = MySQL 5.0.3 sử dụng VARCHAR (2083)

Nguồn

2008-10-20 19:55:27 micahwittman

+12

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

+2

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

+53

Câu trả lời này có 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 nhất quán và có thể thay đổi). Theo liên kết của bạn nói: "* ... đặc tả của giao thức HTTP không chỉ định bất kỳ độ dài tối đa ... *", do đó, không bận tâm với điều đó 'VARCHAR (2083)', chỉ cần sử dụng 'TEXT'. –

32

VARCHAR(512) (hoặc tương tự) phải đủ. Tuy nhiên, vì bạn thực sự không 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 đến TEXT. Sự nguy hiểm với điều này là tất nhiên mất hiệu quả do CLOB s chậm hơn nhiều so với một kiểu dữ liệu chuỗi đơn giản như VARCHAR.

Nguồn

2008-10-20 19:31:31

+0

Điều gì về collation? – kommradHomer

14

varchar(max) cho SQLServer2005

varchar(65535) cho MySQL 5.0.3 và sau đó

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

Nguồn

2008-10-20 19:31:43

+1

Trong đoạn mã của bạn, là 'max' một bộ định danh ANSI SQL ma thuật để tăng kích thước VARCHAR nếu cần thiết, hoặc nó chỉ là một biến meta vì lợi ích của ví dụ? –

+1

Đó là cú pháp SQL2005. Chỉnh sửa. . . –

+4

Trong MySQL bạn rất có thể không có một varchar lớn, trừ khi nó là cột duy nhất trong bảng. – carson

4

Hầu hết các trình duyệt sẽ cho phép bạn đặt very large amounts of data in a URL và do đó rất nhiều thứ sẽ tạo URL rất lớn vì vậy nếu bạn đang nói về bất kỳ thứ gì ngoài phần tên miền của URL, bạn sẽ cần sử dụng cột TEXT từ VARCHAR/CHAR are limited.

Nguồn

2008-10-20 19:33:44 carson

0

Hầu hết các máy chủ web đều 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 số lượng lớn nhất của chúng làm kích thước tối đa của trường; nó phải là quá đủ.

Nguồn

2008-10-20 19:50:11 CesarB

1

Bạn tốt hơn sử dụng varchar(max) (về kích thước) có nghĩa là 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.

Trình chỉ định tối đa mở rộng khả năng lưu trữ của varchar, nvarchar và các loại dữ liệu varbinary. varchar (max), nvarchar (max) và varbinary (max) được gọi chung là các kiểu dữ liệu có 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 this article trên TechNet về việc sử dụng Sử dụng Large-Value Data loại

Nguồn

2012-12-19 10:32:59 sohaiby

+0

'varchar (max)' là cú pháp SQLServer, không thích hợp cho MySQL (như trong câu hỏi gốc). Hơn nữa nó không có nghĩa là 'varchar (65535)' vì 65535 là số ký tự ASCII tối đa trong một hàng trong mysql, do đó, nó cũng phụ thuộc vào các trường khác và trên bộ ký tự. – furins

6

Bạn sẽ muốn lựa chọn giữa một TEXT hoặc cột VARCHAR dựa trên mức độ thường xuyên URL sẽ được sử dụng và cho dù bạn thực sự cần độ dài để không bị ràng buộc.

Sử dụng VARCHAR với maxlength> = 2.083 như micahwittman gợi ý nếu:

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

Sử dụng TEXT nếu:

  1. URL thực sự có thể phá vỡ các giới hạn hàng 65.535 byte
  2. 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 dòng 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.

Nguồn

2013-05-22 22:45:12 mrgrieves

4

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

cách tiếp cận của tôi: sử dụng một hào phóng, nhưng không phải bất hợp lý lớn VARCHAR dài, chẳng hạn như VARCHAR(500) hoặc lâu hơn, và khuyến khích những người dùng cần một URL lớn hơn để sử dụng một shortener URL như safe.mn.

Cách tiếp cận Twitter: Đối với UX thực sự đẹp, hãy cung cấp URL rút gọn 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 đoạn URL có dấu ba chấm ở cuối. (Ví dụ: http://stackoverflow.com/q/219569/1235702 sẽ được hiển thị như stackoverflow.com/q/21956... và sẽ liên kết đến một URL rút ngắn http://ex.ampl/e1234)

Notes và Hãy cẩn thận

  • Rõ ràng, cách tiếp cận Twitter là đẹp hơn, nhưng đối với nhu cầu ứng dụng của tôi, giới thiệu một địa chỉ URL rút ngắn là đủ.
  • Công cụ rút ngắn URL có những hạn chế của chúng, chẳng hạn như mối quan ngại về bảo mật. Trong trường hợp của tôi, nó không phải là một nguy cơ rất lớn bởi vì các URL không được 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 mọi người. safe.mn dường như chặn nhiều spam và URL lừa đảo, nhưng tôi vẫn khuyên bạn nên thận trọng.
  • Hãy nhớ lưu ý rằng bạn không nên buộc người dùng 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 các nhu cầu của ứng dụng của tôi), 500 ký tự quá đủ cho những gì hầu hết người dùng sẽ sử dụng nó cho. 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.

Nguồn

2014-09-08 19:33:20 CullenJ

+8

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

+0

Tất nhiên; nhưng tôi nghi ngờ hầu hết mọi người sẽ viết shortener của riêng mình. Kể từ khi viết này, tôi đã học được rằng có rất nhiều URL rút ngắn URL ra khỏi đó (71 được liệt kê ở đây: http://www.programmableweb.com/news/71-url-shortener-apis-bit.ly-google-url -shortener-and-tiny-url-open/2012/10/31), vì vậy bạn có thể tự động hóa quy trình mà không cần phải tự viết. Nó vẫn phụ thuộc vào kiến ​​thức và sự đồng ý của người dùng, tất nhiên. – CullenJ

7

Bạn nên sử dụng VARCHAR với mã hóa ký tự ASCII. URL được mã hóa phần trăm và 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 UTF8.

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

Nguồn

2015-12-18 10:00:03

+2

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

Các vấn đề liên quan

 Các vấn đề liên quan