我有一个已连接到存储过程的网页。在此SQL数据源中，我有一个参数要传递回int类型的存储过程。

ASP.NET似乎想要默认为int32，但数字不会超过6. 可以覆盖ASP.NET默认值并将其设置为16吗？否则将来会发生冲突吗？

规范：数据库字段的长度为4，精度为10(如果这会导致答案有所不同)。

解决方案

回答

例如，如果我们强制将其设置为一个字节，并且该数字超过255，则可能会导致转换错误(并且会引发异常)。但是，如果我们知道它不会高于6，那应该不是问题。

如果是我，我只会将其用作普通的int，我不确定通过将其设置为字节可以节省很多(如果不是几个字节)。引发异常的风险太高，而使其变小会失去所有好处。

回答

坚持使用int32. 无论如何，这就是vb的"整数"和SQL的INT。

通过使用tinyint / byte或者short / int16而不是int / int32，我们将不会获得任何显着的性能改进。

实际上，将来可能会因对可能期望int32s的对象进行的所有强制转换而引起的头痛。

回答

当我们说DB字段的长度为4时，表示4个字节，相当于一个Int32(4个字节= 32位)。这就是为什么列作为int32返回的原因。

SQL Server中有不同的整数数据类型-如果我们确定数字不会大于6，则应将数据库中的列声明为" tinyint"，该列使用单个字节，并且可以保存0到255之间的值然后，SQL数据源应将其转换为"字节"数据类型，这对于目的将是很好的。

CLR"字节" == SQL" tinyint"(1字节)
CLR" Short"(或者int16)== SQL" smallint"(2字节)
CLR" int32" == SQL" int"

编辑：仅仅因为我们可以做某事，并不意味着我们应该-我同意迈克尔·哈伦(Michael Haren)的观点，管理这些不常见的数据类型带来的开发头痛超过了我们将获得的小小的性能提升，除非我们使用的是非常高性能的软件(在这种情况下，为什么要使用ASP.NET？)

回答

通过在ASP端使用Int16，我们并没有节省太多。最后，它仍然必须将其加载到32位寄存器中。

回答

仅供参考，CLR始终在内部将int映射到Int32.

回答

使用SQLServer存储过程已定义的任何内容。如果它是SQLServer中的" int"，请在.NET中使用Int32. SQL中的smallint是int16。

否则，SQLServer只会自动对其进行升频转换，如果需要对其进行降频转换，则会抛出错误。