Sql 是否有任何原因导致最小值和最大值不在位字段上工作

可能我遗漏了一些东西，但我仍然觉得奇怪，为什么不能在位字段上使用

max

和

min

聚合。因此，如果我尝试这样做：

declare @temp table (data bit)

insert into @temp
select 1 union all
select 0

select max(data) from @temp

declare @temp table (data bit)

insert into @temp
select 1 union all
select 0

select top 1 * from @temp order by data desc

我将得到一个错误

操作数数据类型位对于max运算符无效。

但如果我执行类似操作：

declare @temp table (data bit)

insert into @temp
select 1 union all
select 0

select max(data) from @temp

declare @temp table (data bit)

insert into @temp
select 1 union all
select 0

select top 1 * from @temp order by data desc

它工作正常，因此SQL Server确实知道如何对位字段进行排序。但排序数据的可能性意味着我们可以得到最大值或最小值。

---

那么，这一限制背后的原因是什么呢？

除非我们能够从SQL Server团队获得一些内部信息，否则我们可能不得不接受，有时答案只是“因为”。但是文档非常清楚，例如，州的MSDN页面

MIN可与numeric、char、varchar、uniqueidentifier或 datetime列，但不包含位列

---

我的猜测是（是的，我准备因为在这么一个答案中冒昧地猜测而被激怒！）好处并不大于代码更改的风险。到底有什么好处

---

您不是第一个问这个问题的人，但MS Connect上的回复表明它不太可能改变。

可能不是答案，但作为一种解决方法，您可以简单地使用

CAST（数据为TINYINT）

，这应该足够好了，不？是的，我当然知道解决方法：）但我想知道为什么会有这种限制。还有它对索引行为的影响，我想除了微软以外，没有人知道原因。但根据微软的唯一回答是“这是设计的，我们近期没有任何计划在位列上实现聚合功能”，这可能是初始设计中的疏忽，现在他们没有触及这一点。SQL团队很少在v2之后改进特性，除非有充分的理由。T-SQL语言投资也接近于零。

bit

数据类型有点精神分裂，因为它试图复制布尔的一些语义。也许已经决定MAX（真/假）没有任何意义。但在实践中，这是不方便的。“具体的好处是什么？”更干净的代码。返回正确数据类型的列，而不进行双重强制转换。