Tại sao SQL Server không hỗ trợ kiểu dữ liệu chưa ký?

83

Tôi đang suy nghĩ cụ thể về không dấu int.

Đây là một ví dụ thực tế: bạn sẽ làm gì khi cột danh tính của bạn tối đa? Có thể sử dụng BigInt(bộ nhớ 8 byte thay vì 4) hoặc cấu trúc lại ứng dụng để hỗ trợ số nguyên âm và thậm chí tạo quy tắc của riêng bạn như được chỉ ra trong câu trả lời này ; cả hai lựa chọn đó đều không tối ưu.

UInt sẽ là một giải pháp lý tưởng, nhưng SQL Server không cung cấp nó (khi MySQL thì có).

Tôi hiểu rằng các kiểu dữ liệu không có dấu không phải là một phần của tiêu chuẩn SQL (SQL-2003) nhưng đối với tôi vẫn có vẻ lãng phí.

Lý do của việc không bao gồm những điều này (trong SQL Server hoặc trong tiêu chuẩn) là gì?

— Romhein
nguồn

11

Yêu cầu đội ngũ thiết kế SQL Server ..... thêm: là bạn thực sự sẽ ra tối đa thậm chí 2 TỶ giá trị SẮC INT ?? CÓ THẬT KHÔNG?!?!?! Nếu bạn có nhiều hơn 2 tỷ hàng bất cứ điều gì nó là bạn đang làm việc với, tôi đặt cược bạn có thể tha cho một số không gian đĩa và sử dụng một bigint như SẮC ....

— marc_s

6

Ý bạn là marc_s là gì? Đó chỉ là một lần chèn mỗi 800ms trong 50 năm liên tục, các bảng của bạn không có loại hoạt động đó? :)

— Mike M.

21

@Mike M: Không phải tất cả chúng tôi đều làm việc trên ứng dụng chuột mickey ... chúng tôi đã sử dụng hơn 3 tỷ bigint trong vòng chưa đầy 2 năm. Đỉnh là> 2000 hàng mỗi giây.

— gbn

5

@gbn Tôi không có ý ám chỉ rằng không ai có tải đó. Tuy nhiên, như đã nói, nếu bạn CÓ> 2000 hàng mỗi giây, thì thêm 2B sẽ không giúp ích được gì cho nguyên nhân của bạn.

— Mike M.

9

@Mike M và @marc_s, nếu tôi đang làm việc trên một hệ thống có bảng 2 tỷ hàng, tôi có thể chú ý đến dung lượng bị lãng phí. Tôi có thể chú ý đến kích thước trang chỉ mục và hiệu suất quét chỉ mục. Trong điều kiện như vậy, tôi muốn không lãng phí không gian.

— Romhein

64

Nếu tôi phải đoán, tôi sẽ nói rằng họ đang cố gắng tránh sự gia tăng các loại. Nói chung, không có bất cứ điều gì mà một số nguyên không dấu có thể làm được mà một số nguyên có dấu không thể làm được. Đối với trường hợp khi bạn cần một số từ 2147483648 đến 4294967296, bạn có thể nên chuyển đến một số nguyên 8 byte vì cuối cùng con số này cũng sẽ vượt quá 4294967296.

— Jeff Hornby
nguồn

3

Tôi đoán đây là câu trả lời gần nhất mà chúng ta có thể đưa ra cho câu hỏi này. Cảm ơn.

— Romhein

8

Nếu 'sự gia tăng của các loại' có thể tiết kiệm được một số không gian / tiền bạc, thì tại sao bạn đoán đây có thể là điều xấu.

— Samuel,

1

Việc tìm nạp các hàng theo giá trị của chúng cũng sẽ chậm hơn (tức là ORDER BY ABS(Id)), đặc biệt nếu cột là khóa chính được phân cụm. Ví dụ: sử dụng dấu thời gian 32-bit unix thường là một cách tiện dụng để loại bỏ 4 byte so với ngày giờ chuẩn của SQL.

— Groo

52

Vì mục đích đó, bạn có thể sử dụng -2,147,483,648 làm giá trị hạt giống.

Identity(-2147483648, 1)

— CFreitas
nguồn

46

Tôi đã tìm thấy một câu hỏi tương tự trên Microsoft Office Dev Center.

Câu trả lời từ Jim Hogg (Giám đốc chương trình) có một số ý kiến ủng hộ và phản đối việc thêm int không dấu. Vấn đề lớn là các quy tắc để thực hiện chuyển đổi kiểu ngầm định trở thành một cơn ác mộng để làm đúng.

Yêu cầu đã bị đóng là "Sẽ không khắc phục".

— Anthony K
nguồn

Liên kết không hoạt động nữa, vì vậy tôi không thể đọc câu trả lời gốc. Nhưng tôi tin rằng vấn đề không phải là một cơn ác mộng; đó là không có một tiêu chuẩn nào nói cách thực hiện nó. Ví dụ, họ có thể làm những gì MySQL làm (tôi không nghĩ các DBMS khác hỗ trợ UNSIGNED), nhưng nếu một DBMS khác bổ sung hỗ trợ cho các dấu hiệu, họ có thể sử dụng các quy tắc khác. Thiết kế chuyển đổi là một vấn đề quan trọng. JavaScript là một ví dụ về những gì sẽ xảy ra khi nó không được coi trọng.

— Federico Razzoli

Liên kết cập nhật - Nhận xét của Jim Hogg trên Diễn đàn các nhà phát triển văn phòng MSSN.

— Anthony K

1

Họ không hỗ trợ từ khóa SIGNED và UNSIGNED vì chúng không chuẩn. Trong tiêu chuẩn SQL, tất cả các kiểu số đều được ký.

UNSIGNED (và SIGNED, là mặc định) là phần mở rộng MySQL có thể hữu ích để lưu trữ các số không có dấu cao hơn với cùng một lượng byte và không cho phép các số âm.

— Federico Razzoli
nguồn