Có bất kỳ lý do nào để sử dụng kích thước VARCHAR được làm tròn thành phần bù 128/256 / 4096 byte không?

Trong lược đồ cơ sở dữ liệu, tôi thường nhận thấy các kích thước VARCHAR được làm tròn thành các byte bù 128/256 hoặc 4096. Tôi cũng đã làm điều đó trước đây và ý tưởng đằng sau nó có lẽ là một cái gì đó hiệu quả.

Tuy nhiên, ngày nay vẫn còn một lý do hợp lệ để làm như vậy? Tôi thường sử dụng '50', '100' hoặc '200' làm kích thước VARCHAR hiện nay, vì chúng tự nhiên hơn và thường được hiển thị trong kiểm tra xác thực cho người dùng.

Giải thích hợp lý duy nhất tôi có thể nghĩ đến là: Nếu DBMS lưu trữ các giá trị của cột một cách tuần tự và kích thước không được làm tròn thành lũy thừa 2, thì một số phần tử có thể phải được "chia" thành hai trang trên phần cứng ổ đĩa (ví dụ 10 byte đầu tiên trong trang n và 40 byte tiếp theo trong trang n + 1), trong một số trường hợp có thể dẫn đến hai lần đọc từ ổ đĩa cứng thay vì một.

Nhiều khả năng là quan điểm của @Jan Hudec rằng, nhiều lập trình viên nghĩ "128" hoặc "256" là "số tròn đẹp", khiến chúng trở thành lựa chọn tự nhiên hơn so với các số lẻ như 137, 19 hoặc 100.

Nói chung không có lý do cho những chiều dài cột. Sẽ không có sự cải thiện hiệu suất của cột varchar (100) so với cột varchar (128).

Tuy nhiên, tôi sẽ kiểm tra kỹ hệ thống cơ sở dữ liệu bạn đang sử dụng để làm rõ thêm về các hạn chế và các cảnh báo cụ thể khác của nhà cung cấp.

Ví dụ: đây là một ví dụ hay về hạn chế hệ thống cơ sở dữ liệu cho SQL Server:

http://msdn.microsoft.com/en-us/l Library / ms186981.aspx

Tổng chiều dài của hàng quan trọng hơn độ dài cột riêng lẻ.

Tôi không nhớ đó là DBMS hay trình biên dịch, nhưng tôi nhớ lại (cách đây rất lâu) học cách sử dụng quyền hạn 2 cho độ dài mảng và cột. Có một lý do rằng nó 'nhanh hơn' vì việc triển khai có thể sử dụng dịch chuyển bit. Cho dù giữ đúng nữa là một câu hỏi mở. Bất cứ ai có bất kỳ ý tưởng về việc nó vẫn còn hiệu lực?

BTW Tôi đã di chuyển độ rộng cột thành số đồng nhất b / c, thật lạ khi nói với người dùng giới hạn char là 256 ký tự.

Và một số cơ sở dữ liệu rất cũ đã giới hạn bạn ở 256 cột chiều rộng.

Có lẽ điều đó không thực sự quan trọng, vì bạn thực sự chỉ thấy một số hiệu quả lưu trữ nếu kích thước của toàn bộ hàng của bạn là sức mạnh của 2. Có thể việc gắn với sức mạnh của 2 có thể khiến kích thước hàng của bạn có nhiều khả năng hơn sẽ hoạt động với sức mạnh của hai (vì hầu hết các loại dữ liệu gốc có xu hướng có sức mạnh bằng 2 [tùy thuộc vào cơ sở dữ liệu]), nhưng tôi sẽ không biến nó thành một quy tắc khó và nhanh.

Sẽ có ý nghĩa hơn nếu bạn đang làm việc với các cột lớn (4K hoặc lớn hơn), vì các cột đó có thể được lưu trữ riêng và định cỡ chúng sao cho phù hợp trong một khối lưu trữ (bất cứ điều gì cơ sở dữ liệu của bạn sử dụng cho lưu trữ trên đĩa) sẽ đạt được bạn một cái gì đó

Mặc dù tôi không quen thuộc với tất cả các hệ thống DBMS, đơn vị lưu trữ "vật lý" nhỏ nhất trong Oracle là một "khối" mà theo mặc định là kích thước 2KB. Việc thực hành định cỡ các cột của bạn theo lũy thừa là hai phần của một thực tiễn lớn hơn về kích thước các hàng của bạn để phù hợp với các khối lưu trữ. Định cỡ các cột của bạn để một hàng sẽ yêu cầu nhiều hơn một byte so với kích thước khối sẽ yêu cầu hai khối được phân bổ và hàng của bạn cũng sẽ kéo dài hai khối, khiến việc đọc, chèn và quét tốn nhiều thời gian hơn nếu bạn có thể khớp với mỗi hàng một khối (và chỉ có một hàng trong mỗi khối). Đó, ít nhất, là lý do lịch sử cho nó. Ngày nay, hầu hết mọi người coi thực hành này là tối ưu hóa phụ.