据说,积累经验是个好事儿,这就把这几天遇见的问题记录一下吧,免得哪天又洗脑了那损失就惨重了。
DateTime
DateTime 估计与UNIX时间戳类似,反正是个很精确的记录时间的类型,不过一是可以方便地转换成各种格式的string输出,二是比较精确,单位应该是 Ticks,即CPU时钟周期。用DateTime做数据库的索引是个不错的选择(当然,也可以设成int,然后自动增长),可以保证唯一性又便于按记录 的创建时间排序。只是发现,Sql Server里的DateTime类型比C#里的精度要低,至少要低10^+4,因为好好的DateTime.Now插入到数据库之后再输出,就发现 Ticks的最后四位都是0了,倒数第5位还不是截断出来的,也搞不清是四舍五入还是什么,比如xxxxxxxxxxxx567890,插到数据库里,就 可能变成xxxxxxxxxxxx560000,也可能是570000,还可能是580000或者550000……
另外,DataGridView的Cell显示只到秒量级,所以要使用Convert.toDateTime(Cell[x].value.toString())去数据库里查询,是万万不幸的。。。精度下降了,只到秒量级的话Ticks的最后7位都是0
好在,解决办法是肯定有的,就是取DataGridView的Cells[x].value做查询
如果想省去这些麻烦,对记录的具体插入时间不可以要求的话,用int型键值让它自动增长,也是个不
DateTime
DateTime 估计与UNIX时间戳类似,反正是个很精确的记录时间的类型,不过一是可以方便地转换成各种格式的string输出,二是比较精确,单位应该是 Ticks,即CPU时钟周期。用DateTime做数据库的索引是个不错的选择(当然,也可以设成int,然后自动增长),可以保证唯一性又便于按记录 的创建时间排序。只是发现,Sql Server里的DateTime类型比C#里的精度要低,至少要低10^+4,因为好好的DateTime.Now插入到数据库之后再输出,就发现 Ticks的最后四位都是0了,倒数第5位还不是截断出来的,也搞不清是四舍五入还是什么,比如xxxxxxxxxxxx567890,插到数据库里,就 可能变成xxxxxxxxxxxx560000,也可能是570000,还可能是580000或者550000……
另外,DataGridView的Cell显示只到秒量级,所以要使用Convert.toDateTime(Cell[x].value.toString())去数据库里查询,是万万不幸的。。。精度下降了,只到秒量级的话Ticks的最后7位都是0
好在,解决办法是肯定有的,就是取DataGridView的Cells[x].value做查询
如果想省去这些麻烦,对记录的具体插入时间不可以要求的话,用int型键值让它自动增长,也是个不