Có bất kỳ lý do tốt để giữ ngày và thời gian trong các cột riêng biệt?

Tôi đang cố gắng hiểu quyết định của nhà cung cấp phần mềm của chúng tôi để giữ ngày và giờ trong các cột riêng biệt. Ví dụ: khi hàng được tạo hoặc cập nhật. Cả thời gian và ngày là các cột DateTime. Chúng tôi đang sử dụng SQL Server 2005.

Cơ sở dữ liệu chứa dữ liệu của hệ thống ERP của chúng tôi và tôi tin rằng các bảng lớn nhất chứa khoảng ~ 3 triệu hàng. Hầu hết các bảng có khoảng từ 100 000 - 1 000 000 hàng.

Cá nhân tôi sẽ mặc định chọn một DateTime cho một dấu thời gian duy nhất. Điều này sẽ cho phép tính toán chênh lệch thời gian dễ dàng hơn và các phần ngày và giờ có thể dễ dàng trích xuất từ ​​dấu thời gian. Nó cũng sẽ tiêu tốn ít không gian hơn.

Là tách biệt ngày và thời gian thực hành xấu hoặc có một cái gì đó rất xuất sắc trong thiết kế này tôi không hiểu?

Tôi đoán rằng đó là một thứ hỗ trợ cũ (tức là trong phiên bản 1 của phần mềm của họ, họ có ngày và giờ trong các trường riêng biệt và họ đã buộc phải hỗ trợ vì nó luôn hoạt động theo cách đó).

Điều đó nói rằng, không có gì tuyệt vời về ngày và thời gian riêng biệt, vì vậy bạn không thiếu thứ gì.

(Tùy chọn khác là các nhà phát triển hệ thống ERP của bạn không biết rằng trường thời gian có thể lưu trữ ngày và giờ, nhưng nhiều khả năng là họ có yêu cầu kinh doanh để làm cho nó hoạt động giống như các phiên bản trước.)

Nói chung, nó phụ thuộc vào việc sử dụng. Nếu nhiều truy vấn đang kết hợp các yếu tố phụ với nhau thì hãy xem xét thay vì lưu trữ chúng cùng nhau và sau đó phải chịu trách nhiệm phân tách chúng trong những dịp hiếm hoi đó. Tất nhiên, việc chia tách đôi khi phức tạp hơn (hoặc không thể): xem xét một person_full_namethuộc tính mà bạn cần trích xuất person_family_name. Điều đó nói rằng, việc bỏ một giá trị tạm thời là không đáng kể nên tôi thường thích lưu trữ ngày và thời gian cùng nhau.

Ngoài ra, hãy cân nhắc việc lưu trữ cả hai cùng nhau và với các ràng buộc (và có thể là các trình kích hoạt) để đảm bảo chúng không bị đồng bộ hóa: theo cách này, bạn sẽ thực hiện việc chia tách / tham gia tại điểm cập nhật thay vì tại thời điểm truy vấn dữ liệu.

Tôi không thể thấy nhiều sử dụng cho việc này trong một hệ thống vận hành. Trong một hệ thống phân tích, bạn có thể muốn có thứ nguyên ngày riêng biệt với một hạt 'ngày', vì vậy ngày liên kết với báo cáo ngày tháng và có lẽ là cột 'thời gian' nếu bạn muốn phân tích theo thời gian vì một số lý do .

Bạn cũng có thể trình bày ngày và giờ dưới dạng cột được tính toán dựa trên cột thời gian chính.

Để thêm vào nhận xét của ConcernedOfTunbridge Chúng tôi, có một lợi thế về hiệu năng truy vấn nếu bạn có bảng DateDimension và bảng TimeDimension. Hãy xem xét bảng thực tế có cả dateDimensionKey và TimeDimensionKey. Nếu bạn muốn tìm số thứ gì đó trong khoảng từ 8 giờ sáng đến 5 giờ chiều, bạn chỉ cần làm

SELECT COUNT(1) FROM FactTable f Inner Join TimeDimension t on f.TimeDimensionKey = t.TimeDimension WHERE t.Hour BETWEEN 8 AND 17.

Nếu bạn đã thêm chỉ mục vào TimeDimensionKey, bạn sẽ chỉ cần Tìm kiếm chỉ mục cho kết quả trên bảng thực tế của bạn để tìm kiếm dữ liệu

Nếu không có bảng TimeDimension, bạn sẽ phải làm một cái gì đó như sau,

SELECT COUNT(1) FROM FactTable f WHERE DatePart(mintue, f.Date) BETWEEN 8 AND 17

Điều này có thể sẽ yêu cầu quét bảng vì công cụ cơ sở dữ liệu cần tính toán kết quả cho mỗi hàng trước khi có thể tìm ra dữ liệu nào có thể được trả về.