Kích thước của dateTime2 (0), dateTime2 (1), dateTime2 (2), dateTime2 (3) sử dụng cùng một dung lượng lưu trữ. (6 byte)
Tôi có đúng không khi nói rằng tôi cũng có thể đi với dateTime2 (3) và đạt được lợi ích của độ chính xác mà không có bất kỳ chi phí kích thước bổ sung nào.
Không, bạn giải thích sai tài liệu. Lưu ý các trạng thái lưu trữ tài liệu kích thước 6 byte cho các phân đoạn nhỏ hơn 3 (nhấn mạnh của tôi). Vì vậy, độ chính xác bằng 3 sẽ yêu cầu 7 byte.
Nếu bạn không quan tâm đến mili giây, datetime2(0)sẽ là loại dữ liệu chính xác và chính xác. Thực tiễn tốt nhất là chỉ định loại dữ liệu phù hợp và độ chính xác dựa trên dữ liệu được lưu trữ vì điều này vốn sẽ cung cấp lưu trữ tối ưu và hiệu quả. Điều đó đang được nói, tôi sẽ không mong đợi một tác động hiệu suất đáng kể dựa trên độ chính xác datetime2 được chỉ định miễn là kích thước lưu trữ là như nhau nhưng bản thân tôi chưa kiểm tra cụ thể.
Các yêu cầu ứng dụng sẽ ra lệnh những gì phải được lưu trữ trong cơ sở dữ liệu khi có độ chính xác cao hơn trong nguồn. Ví dụ: đối với thời gian nhập đơn hàng có nguồn gốc từ SYSDATETIME(), người dùng có thể không muốn độ chính xác 100 nano giây. Một lần nữa, chọn loại dữ liệu và độ chính xác để phát triển mới theo yêu cầu và bạn thường sẽ có được hiệu suất tối ưu mà không cần suy nghĩ thêm:
Mặc dù datetime2 thích hợp nhất cho phát triển mới như được liệt kê ở trên, đôi khi người ta có thể cần sử dụng datetime (độ chính xác cố định 3 với độ chính xác 1/300 giây) để tương thích với các ứng dụng datetime kế thừa, do đó tránh chuyển đổi ngầm và hành vi so sánh bất ngờ, nhưng tại chi phí của độ chính xác thứ hai phân đoạn và tăng lưu trữ.
Xem xét rằng việc lưu trữ độ chính xác cao hơn yêu cầu cũng có thể có chi phí phát triển. Nếu một người lưu trữ một thành phần thời gian với giây phân đoạn khi chỉ yêu cầu độ chính xác toàn bộ giây, các truy vấn sẽ vẫn cần xem xét các giây phân số để trả về kết quả chính xác. Ví dụ: với một ứng dụng mà người dùng chọn phạm vi thời gian thông qua giao diện người dùng chỉ cho phép toàn bộ giây, mã ứng dụng sẽ cần tính đến các giây phân số trong giá trị phạm vi thời gian kết thúc và điều chỉnh giá trị do người dùng cung cấp cho phù hợp (ví dụ: WHERE OrderEntryTime BETWEEN '2017-01-11T08:00:00.00.00' AND '2017-01-11T08:59:59.99'hoặc WHERE OrderEntryTime >= '2017-01-11T08:00:00.00' AND OrderEntryTime < '2017-01-11T09:00:00.00'). Điều này sẽ thêm độ phức tạp mã.