Cái nào hiệu quả hơn smallint hoặc ký tự (10)?

Tôi muốn nói rằng thêm một smallint nhân tạo khóa chính sẽ rẻ hơn về không gian lưu trữ, nếu bảng được thiết kế cẩn thận.

Một smallint chiếm 2 byte, trong khi một ký tự character(10) (tức là, phản trực giác, một varlena ) chứa các ký tự ASCII, sẽ tiêu tốn 14 byte.

Trong bảng, 2 byte thừa sẽ bị lãng phí, nhưng đừng quên rằng bạn sẽ có một chỉ mục trên cột khóa chính. Vì vậy, giá trị được lập chỉ mục sẽ thực sự được lưu trữ hai lần:một lần trong bảng, một lần trong chỉ mục.

Vì lợi ích của đơn giản, chúng ta hãy bỏ qua các tiêu đề tuple và các chi phí khác.

• Sử dụng ISBN làm khóa chính sẽ tốn thêm 14 byte cho mỗi hàng trong bảng.

• Thêm smallint khóa chính sẽ thêm hai byte vào bảng và hai byte vào chỉ mục, tạo nên tổng cộng bốn byte được thêm vào.

Vì vậy, hãy thêm một smallint khóa chính nên tiết kiệm dung lượng .

Bạn không nên bỏ qua các vấn đề về căn chỉnh. Tất cả các kiểu dữ liệu được lưu trữ tại các địa chỉ bộ nhớ là bội số của một số lũy thừa nhất định của hai. Điều này được yêu cầu bởi kiến ​​trúc của bộ xử lý. Một smallint thường có căn chỉnh 2, ký tự character có căn chỉnh 1, trong khi ví dụ:timestamp có sự liên kết 8.

Vì vậy, nếu bảng của bạn được xác định là

CREATE TABLE book (
   id smallint PRIMARY KEY,
   issue_time timestamp with time zone,
   isbn character(10)
);

Sau đó, dữ liệu bảng sẽ giống như sau:

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | |X|X|X|X|X|X| | | | | | | | | ... (ISBN omitted)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 id    padding     issue_time

Hàng được căn chỉnh ở ranh giới 8 byte và sáu byte từ cuối if id đến đầu issue_time sẽ trống "padding byte".

Vì vậy, để tận dụng tối đa nó, bạn sẽ phải cân nhắc xem bạn xác định các cột theo thứ tự nào.

Tại sao tất cả những điều này không phù hợp lắm trong thực tế:

Một bảng có 5000 hoặc 10000 mục nhập là rất nhỏ, không có vấn đề gì.

Bất kỳ chi phí nào dành cho việc tối ưu hóa không gian ở đây tốt nhất là tối ưu hóa vi mô không cần thiết.

Nhưng những gì có thể là một ý tưởng thông minh trên bảng lập kế hoạch có thể dễ dàng phản tác dụng sau này:Nếu - khác với những gì bạn mong đợi - bạn muốn lưu trữ 70000 cuốn sách trong bảng, bạn sẽ thấy rằng một smallint sẽ không đủ, ngay cả khi bạn cho phép id phủ định S. Nỗi đau mà bạn sẽ phải chịu đựng khi phải thay đổi kiểu dữ liệu của khóa chính và tất cả các khóa ngoại tham chiếu đến nó trong hệ thống trực tiếp sẽ vượt xa mọi niềm vui mà bạn nhận được khi tiết kiệm được khoảng 100 KB bằng cách tối ưu hóa thông minh.