我应该将DateTimes作为Long（Ticks）存储在数据库中吗？

Question

将DateTime值保存为long可以让生活更轻松吗？使用null DateTime值时似乎总是存在问题，无论是存储还是检索 - null DateTimes，无效的DateTimes等总是很难处理。

简单地使用long数据类型是否可取，因为您始终可以从刻度线创建DateTime？

编辑： 我使用SqlServer和MySql。 SqlDateTime是DateTime的.net派生。有效 DateTime 的所有3个平台之间存在差异。你如何处理这些差异？

Answer 1

我想这取决于个人偏好。我总是使用日期时间类型，并且没有任何麻烦。

如果你通过语义将它们存储为长片，则它们不再是日期。如果您曾经想要进行查询以选择星期五（例如）添加的所有帐户，那么您将不得不跳过几个环节来解决这个问题。

Answer 2

我个人无法想到任何出色的理由，数据库支持DateTime自己，并且存储它们很长时间你可能会最终在脚下射击。假设您需要能够运行查询“在凌晨3点到下午6点之间获取所有行” - 如果将它们存储为刻度线，则需要转换回数据库中的DateTime。

将它们存储为刻度可能会阻碍许多其他操作，例如分组，排序，过滤等。

如果数据库中有DateTimes的细微差别，例如TimeZone，强烈建议将DateTime规范化为特定的时区，例如UTC。团队在数据库中遇到的许多问题通常是由于不卫生的输入，比如没有规范化TimeZone。将其存储为刻度仍将存在同样的问题。

Answer 3

不，使用datetime列。

  

使用null DateTime值

时似乎总是存在问题

如果您的列可以为空，并且当列的类型为datetime时由于某种原因您遇到困难，那么当列的类型为long时，您也会遇到问题。

  

...无效的DateTimes

如何在datetime列中获取无效的日期时间？使用datetime列开始的目的之一是在允许插入数据之前进行某种验证。使用裸long时，你很可能会得到无效的日期时间。

最后，使用long意味着通过简单的SQL（select * from table）查看数据库将产生难以辨认的结果。

Answer 4

在某些情况下，是的。 Sql以比DateTime更低的精度存储日期时间。这意味着持久化和检索的值可能与原始对象的DateTime值略有不同，这可能会导致排序或比较时出现一些问题。