datetime字段和bigint字段组成组合键或者Unique Index时，精度会发生变化吗？
Does the precision of datetime field change when used with bigint field to form a composite key or Unique Index?
我需要使用由 bigint 数据类型和 datetime 数据类型组成的复合键或唯一索引。但是，我注意到日期时间的秒元素已四舍五入到最接近的分钟，并在尝试导入数据集时导致重复键冲突。
数据集本质上是交易数据，所以我们的ID（存储在bigint字段中）会重复，因此需要在唯一键中包含datetime字段。
举个例子：下面两行导致'duplicate key row'错误：
ID 字段 (bigint) |动作日期（日期时间）
------------------ |-------------------------
1050000284002 | 2016-01-08 15:51:24.000
1050000284002 | 2016-01-08 15:50:35.000
值明显不同（并正确存储在数据库中）但错误显示：
The duplicate key value is (1050000284002, Jan 8 2016 3:51PM).
（值得补充的是，我最初创建了一个组合键，后来用唯一索引替换了它；上面列出的错误是在索引就位时生成的。）
我的问题是：
- 我的日期时间字段是否因为我在 key/index 中使用整数而被四舍五入？
- 我丢失日期时间字段的时间部分的准确性还有其他原因吗？
- 我怎样才能纠正这个问题，使该示例不会导致密钥冲突？
当我这样做时：
declare @i bigint
set @i=25
select @i+getdate()
select cast ( @i+getdate() as int)
我得到：
2016-10-17 09:47:05.753
42658
注意第一个结果是日期加上 25 天。因此日期的整数部分没有下降（否则日期将是午夜......）。
第二个select删除小数点后的所有内容....
如果您使用的索引形式（A、B 列的索引）而不是公式索引（A + B 列的索引），则不会，一列的数据类型不会影响其他的内容。
根据您的描述，我会检查以下内容：
- 日期时间列的实际数据类型。是日期时间吗？ （日期时间将四舍五入到最接近的 333 秒，尽管这不是这里的问题。）
- 索引的实际定义。是像你想的那样定义的吗？也许它是在日期（DateTimeColumn）上建立索引？
- 正在存储的实际数据。将数据加载到 table 中的任何东西是否会截断秒数？
根据您的修改提出的进一步建议：
如果您正在导入的数据明确包含唯一的日期时间值，但 SQL 没有识别唯一的日期值，那么数据导入过程出了点问题。
尝试将您的数据加载到 table 而没有 索引。它加载了吗？它是否将您的源数据匹配到毫秒？现在，加载数据后，创建索引（主键、唯一约束等）。这会失败吗？哪里来的重复数据？简而言之，弄乱数据和加载过程，看看会发生什么。
我需要使用由 bigint 数据类型和 datetime 数据类型组成的复合键或唯一索引。但是，我注意到日期时间的秒元素已四舍五入到最接近的分钟，并在尝试导入数据集时导致重复键冲突。
数据集本质上是交易数据，所以我们的ID（存储在bigint字段中）会重复，因此需要在唯一键中包含datetime字段。
举个例子：下面两行导致'duplicate key row'错误：
ID 字段 (bigint) |动作日期（日期时间）
------------------ |-------------------------
1050000284002 | 2016-01-08 15:51:24.000
1050000284002 | 2016-01-08 15:50:35.000
值明显不同（并正确存储在数据库中）但错误显示：
The duplicate key value is (1050000284002, Jan 8 2016 3:51PM).
（值得补充的是，我最初创建了一个组合键，后来用唯一索引替换了它；上面列出的错误是在索引就位时生成的。）
我的问题是：
- 我的日期时间字段是否因为我在 key/index 中使用整数而被四舍五入？
- 我丢失日期时间字段的时间部分的准确性还有其他原因吗？
- 我怎样才能纠正这个问题，使该示例不会导致密钥冲突？
当我这样做时：
declare @i bigint
set @i=25
select @i+getdate()
select cast ( @i+getdate() as int)
我得到： 2016-10-17 09:47:05.753
42658
注意第一个结果是日期加上 25 天。因此日期的整数部分没有下降（否则日期将是午夜......）。
第二个select删除小数点后的所有内容....
如果您使用的索引形式（A、B 列的索引）而不是公式索引（A + B 列的索引），则不会，一列的数据类型不会影响其他的内容。
根据您的描述，我会检查以下内容：
- 日期时间列的实际数据类型。是日期时间吗？ （日期时间将四舍五入到最接近的 333 秒，尽管这不是这里的问题。）
- 索引的实际定义。是像你想的那样定义的吗？也许它是在日期（DateTimeColumn）上建立索引？
- 正在存储的实际数据。将数据加载到 table 中的任何东西是否会截断秒数？
根据您的修改提出的进一步建议：
如果您正在导入的数据明确包含唯一的日期时间值，但 SQL 没有识别唯一的日期值，那么数据导入过程出了点问题。
尝试将您的数据加载到 table 而没有 索引。它加载了吗？它是否将您的源数据匹配到毫秒？现在，加载数据后，创建索引（主键、唯一约束等）。这会失败吗？哪里来的重复数据？简而言之，弄乱数据和加载过程，看看会发生什么。