标签: sql-server

我见过很多人使用 COALESCE 函数代替 ISNULL。从 Internet 搜索中，我发现 COALESCE 是 ANSI 标准，因此有一个优势，即我们知道使用它时会发生什么。然而， ISNULL 似乎更容易阅读，因为它似乎更清楚它在做什么。

我也意识到 ISNULL 有点棘手，因为它在不同的数据库服务器和不同的语言中表现不同。

在我看来，所有这些都归结为风格和标准。鉴于风格是主观的，有没有理由在 ISNULL 上使用 COALESCE（反之亦然）？具体来说，一个比另一个有性能优势吗？

我今天有一个由其他人创建的 .bak 文件，通过 SSMS 2008 R2 手动创建。我正在尝试手动恢复数据库，不幸的是，当我浏览它时该文件没有出现。

我可以编写恢复过程的脚本，但我以前见过这个问题，我不确定是什么原因导致 .bak 不出现。

众所周知，SCHEMABINDING一个函数可以避免更新计划中不必要的假脱机：

如果您使用不涉及任何表（即不访问数据）的简单 T-SQL UDF，请确保SCHEMABINDING在创建 UDF 期间指定该选项。这将使 UDF 模式绑定并确保查询优化器不会为涉及这些 UDF 的查询计划生成任何不必要的假脱机运算符。

SCHEMABINDING即使不访问数据，函数还有其他优势吗？

鉴于以下组件

DECLARE @D DATE = '2013-10-13'
DECLARE @T TIME(7) = '23:59:59.9999999'

将它们结合起来以产生DATETIME2(7)具有价值的结果的最佳方法是'2013-10-13 23:59:59.9999999'什么？

有些东西不工作，如下表所示。

SELECT @D + @T 

操作数数据类型日期对加法运算符无效。

SELECT CAST(@D AS DATETIME2(7)) + @T 

操作数数据类型 datetime2 对加法运算符无效。

SELECT DATEADD(NANOSECOND,DATEDIFF(NANOSECOND,CAST('00:00:00.0000000' AS TIME),@T),@D)

datediff 函数导致溢出。分隔两个日期/时间实例的日期部分数量太大。尝试将 datediff 与不太精确的日期部分一起使用。

* 可以在 Azure SQL 数据库和 SQL Server 2016 中避免溢出，使用DATEDIFF_BIG.

SELECT CAST(@D AS DATETIME) + @T 

数据类型 datetime 和 time 在 add 运算符中不兼容。

SELECT CAST(@D AS DATETIME) + CAST(@T AS DATETIME)

返回结果但失去精度 2013-10-13 23:59:59.997

可能的重复：
为什么使用 int 作为查找表的主键？

到目前为止，我习惯于为每个表创建一个 ID 列，它的实用性使我不必考虑有关主键理论的决策。

我大学的教授建议全班从一个或多个字段制作主键，这些字段构成关于每一列的一个唯一信息。是的，我想养成使用自然键而不是代理键的习惯。维基百科上列出了代理键的优缺点，我严格推荐这篇文章

我见过人们对所有内容都使用整数 ID 字段，但没有人评判这种方法，因为

• 它“看起来”高效
• 使用了一个数字字段，它看起来更酷，因为它在内存中每行的大小

我开始认为额外的 ID 字段只是创建冗余数据而没有实际好处。那么当我可以使用其他列作为关键字段时，为什么还要创建 ID 列呢？

• 如果您的 ID 字段是 32 位，则它已经相当于 4 个 ASCII 字符。
• 如果您的 Id 字段是64 位整数，则它是8 个字符的字符串，因此它实际上并没有节省那么多内存（这里暗示的是用于比较的内存。额外的 id 列已经添加到使用的内存中（HDD 和 RAM） ) )
• 额外的 ID 字段会使您的索引成本加倍，因为您还将索引一个可以用作主键的唯一字段。
• 如果您需要可以用作关键字段的数据，则进行额外的联接，例如，如果您在一篇博客文章中存储了唯一的用户 ID，以显示作者姓名，则进行联接查询，如果您的密钥字段是作者的名字，你不需要加入，因为你将相关数据存储在博客帖子表中。具有有意义数据的外键字段减少了子查询或连接的需要