Máy chủ SQL thập phân (9, 0) so với INT

Một trong những khách hàng của chúng tôi sử dụng cho một số cột kiểu dữ liệu DECIMAL(18,0)trong cơ sở dữ liệu SQL Server 2008R2 của anh ấy. Vì các cột phát triển khá chậm, gần đây, ông đã đề xuất thay đổi kiểu dữ liệu DECIMAL(5,0)để lấy lại một số lưu trữ.

Theo thư viện MSDN , không gian lưu trữ của DECIMAL(5,0)kiểu dữ liệu, giống như DECIMAL(9,0)kiểu dữ liệu, 5 byte. INTlà 1 byte nhỏ hơn, nhưng có thể lưu trữ tất cả mọi thứ trong khoảng từ -2 ^ 31 đến 2 ^ 31 thay vì -99.999 đến 99.999 mà DECIMAL(5,0)có thể lưu trữ. Ngay cả số lớn nhất DECIMALphù hợp với 5 byte ( DECIMAL(9,0)) chỉ có thể lưu trữ các số nguyên trong phạm vi -999.999.999 đến 999.999.999 (ít hơn một nửa phạm vi INTcung cấp trong 4 byte).

Tôi có thể nghĩ về hai "lợi ích" của việc sử dụng DECIMALhơn INT:

Khả năng thêm tỷ lệ sau đó, mà không cần sử dụng thêm dung lượng lưu trữ
Khả năng mở rộng độ chính xác lên tới 38 chữ số mà không làm thay đổi kiểu dữ liệu

Nhưng theo tôi thì đây không phải là lợi ích thực sự:

Thêm tỷ lệ vào số nguyên chỉ có ý nghĩa trong rất ít trường hợp (trong hầu hết các trường hợp quy mô tạo ra sự khác biệt, nó cũng có thể được thêm vào trước)
SQL Server xem mọi kết hợp độ chính xác / tỷ lệ là một kiểu dữ liệu khác nhau, vì vậy kiểu dữ liệu không bị bỏ lại một mình khi tăng độ chính xác hoặc tỷ lệ.

Điều này khiến tôi tự hỏi: lợi ích bổ sung của DECIMAL(5,0)kiểu dữ liệu cho số nguyên là gì?

sql-server t-sql datatypes

— vstrien
nguồn

Một lợi ích có thể là giới hạn năm chữ số. Nhưng tôi tự hỏi bạn có thể dành bao nhiêu dung lượng lưu trữ với một sự thay đổi như vậy.

— dezso

IMO, nếu bạn chỉ cần đảm bảo các giá trị cột nằm trong một phạm vi, hãy sử dụng ràng buộc kiểm tra. Tôi nghĩ rằng sự cân nhắc duy nhất ở đây sẽ là nếu có khả năng cột này yêu cầu các giá trị phân số trong tương lai.

— Jon Seigel

Nếu họ lo lắng về không gian lưu trữ, họ sẽ phù hợp hơn khi sử dụng tính năng nén hơn mức này. Không có lợi ích hữu hình khi sử dụng số thập phân (x, 0) thay vì int / bigint.

— Robert L Davis

Một sự khác biệt khác giữa decimal(x,0)và một kiểu số nguyên thể hiện chính nó trong phân chia số học. Nếu bạn chia một int cho một int, bạn sẽ nhận được một int. Nếu bạn chia một số thập phân (x, 0) cho một số nguyên, bạn sẽ nhận được một số thập phân (x + 6,6).

— Andriy M

@AndriyM, tôi nghĩ đây là lợi ích lớn nhất. Viết lại nó thành một câu trả lời thay vì một bình luận và tôi sẽ đánh dấu nó là câu trả lời.

— vstrien

Câu trả lời:

Tôi đồng ý rằng không có lợi ích thực sự về mặt lưu trữ không gian miễn là bạn đang so sánh DECIMAL (9, 0) so với INT hoặc DECIMAL (18, 0) so với BIGINT. (Trong một byte đơn.)

Về mặt xử lý, như @Andriy nói rằng DECIMAL sẽ tự nhiên phân chia thành một loại không làm mất phần phân số, nếu điều đó quan trọng đối với bạn.

Mặt khác, làm việc với các kiểu INT gốc nhanh hơn nhiều so với quan điểm số nếu bạn đang thực hiện nhiều SUM () hoặc so sánh (chẳng hạn như tìm kiếm trên các giá trị) vì chúng được CPU xử lý hiệu quả hơn. Một so sánh int là hai opcodes lắp ráp (MOV, CMP) nhưng bất kỳ so sánh thập phân nào cũng sẽ nhiều, nhiều hơn nữa.

— Chris Chubb
nguồn

Câu trả lời của bạn có ý nghĩa, nhưng một bộ xử lý không có bất kỳ kiến thức nào về kiểu dữ liệu. Vì vậy, một kiểu dữ liệu gồm 4 byte, được so sánh nhanh như một kiểu dữ liệu khác có 4 byte. Bạn có thể hiển thị (với một bài kiểm tra hiệu suất lặp lại, ví dụ) rằng có một buổi biểu diễn hit trong việc sử dụng DECIMAL(9, 0)thay vì một INT?

— vstrien

Tôi nghĩ rằng tôi có thể, nhưng tôi sẽ thừa nhận rằng các xét nghiệm của tôi là không kết luận. Có lẽ SQL đang thực hiện tối ưu hóa để giảm bài toán thành toán nguyên. Thử nghiệm của tôi: `- Không so sánh SET @StartTime = SYSDATETIME () WHILE (@CountINT <@SizeINT) SET @C gặpINT = @C gặpINT + 1 PRINT 'INT lấy' + CONVERT (VARCHAR (20), DATEDIFF (millisecond , SYSDATETIME ())) + 'mili giây' - SET tối ưu @StartTime = SYSDATETIME () WHILE (@CountDEC <@SizeDEC) SET @CountDEC = @C gặpDEC + 1 PRINT 'DEC đã' + CHUYỂN ĐỔI (20) (mili giây, @StartTime, SYSDATETIME ())) + 'mili giây' `

— Chris Chubb

Tôi nghĩ rằng SQL Server tối ưu hóa một cái gì đó thực sự có. Mặc dù việc tối ưu hóa DECIMALvẫn thường mất nhiều thời gian hơn (ít nhất là trên hệ thống phát triển của tôi). Trong 10 lần thử nghiệm khoảng 51 ms DEC so với 46 ms INT.

— vstrien

Có vẻ như sẽ không có lợi ích về không gian lưu trữ.

Nếu khách hàng của bạn lo ngại rằng các giá trị của bạn sẽ lớn hơn 2 ^ 32-1 (số nguyên giá trị dương tối đa có thể lưu trữ) thì bạn nên xem xét chuyển sang BigInt - với 64 bit ( 8 byte) .

— AlexTheDeveloper
nguồn