2011-03-04 20 views
5

Cuộc sống có thể được thực hiện dễ dàng hơn bằng cách lưu các giá trị DateTime dưới dạng long thay thế? Luôn luôn có vẻ là vấn đề khi làm việc với các giá trị DateTime null, cho dù lưu trữ hoặc truy xuất - null DateTimes, DateTimes không hợp lệ, vv luôn là một nỗi đau để làm việc với.Tôi có nên lưu trữ DateTimes như là một Long (Ticks) trong một cơ sở dữ liệu?

Bạn có nên làm việc đơn giản với loại dữ liệu long vì bạn luôn có thể tạo DateTime từ các dấu tích không?

Chỉnh sửa: Tôi làm việc với SqlServer và MySql. SqlDateTime là một dẫn xuất .net của DateTime. Có sự khác biệt giữa tất cả 3 nền tảng của DateTime hợp lệ. Làm thế nào để bạn xử lý những khác biệt này?

+2

ngày giờ có lý do: sử dụng nó. –

+0

Ngày giờ có sẵn để thuận tiện, IMO. Tôi chỉ đơn giản xem xét việc lưu các giá trị DateTime như các dấu tích trong cơ sở dữ liệu. Lấy ra một thời gian dài từ cơ sở dữ liệu cho tôi những gì tôi cần để tạo ra một DateTime từ số lượng bọ ve. Tôi không thấy một vấn đề với nó. – IAbstract

+2

Làm cách nào để giải quyết vấn đề với 'datetime' bằng cách sử dụng' long'? –

Trả lời

7

Tôi đoán đó là tùy chọn cá nhân. Tôi luôn luôn làm việc với các loại datetime và không có bất kỳ bận tâm với họ.

Nếu bạn lưu trữ chúng lâu dài mặc dù ngữ nghĩa chúng không còn là ngày nữa. Nếu bạn đã bao giờ muốn thực hiện một truy vấn để chọn tất cả các tài khoản được thêm vào ngày thứ Sáu (nói), bạn sẽ phải nhảy qua một số vòng để làm việc đó.

+5

Đốt hoops chết và hủy diệt. – Max

4

Tôi không thể nghĩ ra bất kỳ lý do nổi bật nào, cơ sở dữ liệu hỗ trợ bản thân DateTime và lưu trữ chúng trong một thời gian dài mà bạn có thể sẽ tự quay mình. Giả sử bạn cần có khả năng chạy truy vấn "Đưa cho tôi tất cả các hàng từ 3 giờ sáng đến 6 giờ chiều" - nếu bạn lưu trữ chúng dưới dạng bọ ve, bạn sẽ cần phải chuyển đổi về DateTime trong cơ sở dữ liệu.

lưu trữ chúng như bọ ve có thể cản trở nhiều hoạt động khác, chẳng hạn như nhóm, phân loại, lọc vv

Nếu bạn có những sắc thái với DateTimes trong cơ sở dữ liệu, chẳng hạn như TimeZone, nó khuyến khích mạnh mẽ để bình thường hóa các DateTime để một múi giờ cụ thể, chẳng hạn như UTC. Rất nhiều vấn đề mà các đội phải đối mặt với DateTime trong cơ sở dữ liệu thường là do đầu vào không hợp vệ sinh, như không bình thường hóa TimeZone. Lưu trữ nó như bọ ve vẫn sẽ có cùng một vấn đề.

+0

Điểm tuyệt vời trên các truy vấn: +1 – IAbstract

2

Không, sử dụng cột datetime.

Có luôn dường như là vấn đề khi làm việc với null DateTime giá trị

Nếu cột của bạn là nullable, và bạn vì một lý do gặp khó khăn khi loại cột là datetime bạn cũng sẽ có vấn đề khi loại cột là long.

... DateTimes không hợp lệ

Làm thế nào để bạn có được datetimes không hợp lệ vào một cột datetime? Một trong những mục đích của việc sử dụng cột datetime để bắt đầu là loại xác thực đó xảy ra trước khi dữ liệu được phép chèn vào. Nhiều khả năng bạn sẽ nhận được thời gian sử dụng không hợp lệ khi sử dụng một số long trần truồng.

Cuối cùng, sử dụng long có nghĩa là xem cơ sở dữ liệu của bạn qua SQL đơn giản (select * from table) sẽ tạo ra kết quả không đọc được.

+0

dường như có sự khác biệt giữa những gì SqlServer, MySql và .Net coi là giá trị DateTime không hợp lệ ... – IAbstract

+0

@IAbstract, thực sự - luôn luôn hữu ích khi cụ thể trong câu hỏi của bạn . Bạn đang hỏi về một cơ sở dữ liệu cụ thể? –

+0

Vào thời điểm đó tôi đã có câu hỏi này tôi đã kéo dữ liệu từ SQL Server & MySQL. Tôi không nhớ tất cả các chi tiết cụ thể nhưng DateTime được chơi từ tất cả 3 nền tảng (.Net incl.) Vì vậy việc lưu trữ DateTime như một thời gian dài sẽ là "phổ quát". Tôi tin rằng tôi có thẩm quyền và quyền truy cập để sửa đổi chỉ một trong những cơ sở dữ liệu mà có thể đã làm cho cuộc sống của tôi dễ dàng hơn ở phía bên .Net của sự vật (như một trung gian). Nếu không, tôi không quan tâm đến tính dễ đọc của các giá trị dài trong cột * DateTime * nếu có thể, nếu cần, sử dụng hàm ngày tháng/proc để hiển thị ngày theo nền tảng tương ứng. – IAbstract

2

Trong một số trường hợp, có. Sql lưu trữ các datetimes ở độ chính xác thấp hơn DateTime.Điều này có nghĩa là một giá trị được lưu giữ và truy xuất có thể có giá trị DateTime hơi khác so với đối tượng ban đầu, điều này có thể gây ra một số vấn đề khi đặt hàng hoặc so sánh.

Các vấn đề liên quan