2012-02-23 13 views
8

Tôi hiểu rằng 2, 4, 8, 16, 32, 64, 128, 256 ... là các số thập phân tương đương của các chữ số nhị phân.Tại sao lược đồ cơ sở dữ liệu thường chứa 32, 64, 128, v.v.

Có lý do nào khiến chúng được sử dụng trong cơ sở dữ liệu không? Ví dụ, các trường VARCHAR thường dài 255 ký tự. Kể từ khi (tôi giả định) mỗi ký tự là một byte, tại sao có sự khác biệt giữa việc sử dụng 255 ký tự và sử dụng 257 ký tự?

Trả lời

4

Với varchar cột, dài được lưu trữ với dữ liệu bằng số nguyên unsigned trong byte hàng đầu của dữ liệu. Số byte ít nhất được sử dụng; một byte có thể lưu trữ độ dài từ 0 đến 255, hai byte từ 0 đến 65535, v.v. Bằng cách thực hiện chiều dài 255, bạn nhận được "giá trị cao nhất" trong số byte dài tối thiểu.

Trong những ngày trôi qua, một byte đĩa được lưu trên mỗi hàng có giá trị tiết kiệm. Mặc dù bây giờ đĩa là rẻ, nhưng suy nghĩ vẫn còn, đặc biệt là bởi các DBA tóc xám.

Không có lợi thế khi chọn độ dài là 2, ví dụ varchar(64) - nó chỉ là thói quen/quy ước (tôi thậm chí theo dõi nó - và tôi không biết tại sao!).

+0

Ouch. Tôi có mái tóc màu xám nhưng tôi không phải là cũ (38). :-) –

+0

Hmm, mặc dù trong các bảng lớn nơi bạn cần thực hiện các cuộc gọi SELECT yêu cầu nhiều I/O, tiết kiệm một vài byte kích thước hàng * có thể * tạo sự khác biệt. (Nhưng bạn hoàn toàn đúng về chiều dài VARCHAR mặc dù :) – osman

+1

@osman yes - các hàng và/hoặc chỉ mục nhiều hơn bạn có thể phù hợp trong 1 trang của đĩa hiệu suất tốt hơn. – Bohemian

1

Không chỉ đơn thuần là lược đồ cơ sở dữ liệu mà còn nhiều phần mềm lập trình sẽ được tìm thấy chứa nhiều số dạng 2^N hoặc 2^N-1. Mặc dù một số trong số này sử dụng có ý nghĩa (ví dụ: 2^32-1 là số lớn nhất có thể đại diện như một số nguyên không dấu tiêu chuẩn trong nhiều kiến ​​trúc máy), hầu hết việc sử dụng các quyền hạn của 2 ít cần thiết hơn. Trong thực tế, tin tặc cũ xem sức mạnh của 2 như thánh thiện, và tôn kính họ như vậy.

+0

Các thứ khác sẽ xếp hàng độc đáo như thế nào khi bạn xem một kết xuất dữ liệu hex? ;-) – mpontillo

1

Dữ liệu trong cơ sở dữ liệu thường được tổ chức theo số pages. Các trang này hầu như được căn chỉnh với ranh giới bộ nhớ để quản lý bộ nhớ và bộ nhớ cache. Chọn kích thước 2^n cho dữ liệu của bạn là tốt để tối ưu hóa việc sử dụng không gian trong cơ sở dữ liệu của bạn. Lưu ý: Tùy thuộc vào công cụ RDBMS, 256 có thể không phải là lựa chọn tốt nhất cho các chuỗi có độ dài thay đổi từ phối cảnh liên kết bộ nhớ, bởi vì chiều dài của chuỗi cũng chiếm không gian, tức là varchar(256) chiếm 258 byte.

+0

Trừ khi kích thước dữ liệu được cố định (char/nchar), điều này không đúng với các cột độ dài khác nhau, có nhiều khả năng được xác định bằng cách sử dụng các số ma thuật này, và hiếm khi được điền hoàn toàn và do đó không đồng đều lấp đầy một trang trong các khối nhỏ đẹp. –

+0

@AaronBertrand Đó là điểm tôi đã cố gắng để thực hiện trong lưu ý ở phần cuối của câu trả lời: 2^n số cho 'varchar' cột không có khả năng giúp với sự liên kết trang. – dasblinkenlight

+0

Xin lỗi, tôi đã bắt đầu nhận xét của mình sau khi hoàn thành đoạn đầu tiên. Đề xuất nói điều gì đó về "dữ liệu cố định" thay vì chỉ "dữ liệu" trong trường hợp những người khác cũng không đọc ghi chú của bạn. :-) –

1

Đó là thói quen nhiều hơn bất cứ điều gì. Không có gì kỳ diệu về varchar (32) hoặc varchar (64), tương tự như không có gì phép thuật về mặc định các công cụ trực quan cố gắng để làm cho bạn sử dụng thay vào đó (ví dụ: varchar (50)). Rất nhiều giới hạn trên đã được ăn sâu vào đầu người từ 640k sẽ là đủ bộ nhớ cho bất cứ ai và chúng tôi thực sự cần phải lo lắng về từng byte đơn lẻ.

Trong nhiều trường hợp, nó rơi xuống một nền tảng chung. Trong một hệ thống trước đó, tôi làm việc trong các nhà quản lý sản phẩm không biết yêu cầu của họ là gì. Họ muốn lưu trữ một cái tên, nhưng họ không biết tên miền thực sự bao gồm cái gì - nhưng một trong số họ đã nói rằng họ đã nghe về họ> 50 ký tự, vì vậy anh biết nó phải hơn 32 và hơn 50. Chúng tôi đã trở lại với 64, ông đã đồng ý rằng là đủ, và đó là những gì vẫn còn đó ngày hôm nay AFAIK.

Mặc dù chúng tôi đã có lý do kỹ thuật cho e-mail (varchar (320)), tại thời điểm tiêu chuẩn được quy định là 320 ký tự vì 64 ký tự cho tên người dùng/localpart, 255 ký tự cho tên miền và 1 ký tự cho @. Hầu hết các quyết định khác đều dựa trên quyền ưu tiên (ví dụ: tất cả các tên tiếp theo theo mô hình nvarchar (64) như đã quyết định ở trên) hoặc logic (ví dụ: URL không cần phải là nvarchar (tối đa), nhưng tùy thuộc vào khả năng tiêu chuẩn và trình duyệt tại thời gian, họ đã tin rằng một trong hai varchar (2048) hoặc varchar (4096) Trong trường hợp đó không phải vì nó là một sức mạnh của 2, nhưng vì phần mềm hoặc tiêu chuẩn của người khác xây dựng công cụ của họ để sử dụng một sức mạnh của 2.

+0

+1 vì bạn (tôi nghĩ) đề xuất các tiêu chuẩn tư vấn, ví dụ: đối với tên gia đình người tôi muốn sử dụng 'VARCHAR (35) 'để phù hợp với [tiêu chuẩn dữ liệu của chính phủ quốc gia của tôi] (http://interim.cabinetoffice.gov.uk/govtalk/schemasstandards/e-gif/datastandards/person_information/person_name/ person_full_name.aspx), một phần vì phần mềm của tôi có khả năng tương tác với cơ sở dữ liệu của chính phủ nhưng cũng bởi vì ai đó đã thực hiện phân tích để xác định rằng 35 ký tự không phải Unicode là một ràng buộc hợp lý để tôi không phải! – onedaywhen

+0

Có, tuyệt đối, nếu có các tiêu chuẩn dữ liệu cho ngành của bạn, bạn nên sử dụng chúng. Nhưng khách hàng và người quản lý sản phẩm của bạn - những người cũng là khách hàng của bạn - thường có thể ra lệnh khác, và con át chủ bài của họ thường đánh bại át chủ bài (trừ khi họ ngu ngốc hoặc vô lý). Và họ sẽ kiểm tra xem bạn có thực sự cho phép họ có 64 ký tự hay không, hãy tin tôi đi. :-) –

+0

Tôi tự hỏi liệu, nếu ai đó đề xuất sử dụng 'NVARCHAR' thay vì' VARCHAR', tôi sẽ được biện minh khi lấy [lá ra khỏi cuốn sách của Joe Celko] (http://books.google.co.uk/books ? id = a9jtyioHfp8C & pg = PA131 & lpg = PA131 & dq = celko + phật giáo & source = bl & ots = Py_oNKC6_h & sig = d9MRYEcVlI-Noi03XWLaDhAv6WM & hl = vi & sa = X & ei = D0VGT6SzAYbN0QXa7KmmDg & ved = 0CCAQ6AEwAA # v = onepage & q & f = false) và đặt Unicode của Trung Quốc vào đó? ;) – onedaywhen