ASP.NET中的默认整数类型，来自存储过程

Question

我有一个网页，我已经连接到stored procedure。在这个SQL数据源中，我有一个参数，我将其传递回int类型的存储过程。

ASP.NET似乎要默认为 int32 ，但数字不会高于6.是否可以覆盖ASP.NET默认值并输入16或将未来某个地方会发生冲突吗？

规范：数据库字段的长度为4，精度为10，如果这样会对答案产生影响。

Answer 1

如果强制它为例如一个字节并且数字超过255，则存在转换错误的风险（并且将抛出异常）。但是，如果你知道它不会高于6，那应该不是问题。

如果是我，我会把它当作普通的int使用，我不确定如果除了几个字节以外的任何东西，通过使它成为一个字节来节省很多。抛出异常的风险太高，你可以通过缩小它来失去所有好处。

Answer 2

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

使用tinyint / byte或short / int16而不是int / int32，不会获得任何显着的性能提升。

事实上，将来可能会遇到的令人头疼的问题是，你可能不得不为那些期望int32s的对象做出的所有转换会让你发疯。

Answer 3

当您说DB字段的长度为4时，这意味着4个字节，相当于Int32（4个字节= 32位）。这就是你的列作为int32返回的原因。

SQL Server中有不同的integer datatypes - 如果您确定数字不会高于6，则应将数据库中的列声明为“tinyint”，它使用单个字节并且可以保存0到255之间的值。然后SQL数据源应该将其转换为“byte”数据类型，这对于您的目的来说没问题。

CLR“byte”== SQL“tinyint”（1个字节） CLR“Short”（或int16）== SQL“smallint”（2个字节） CLR“int32”== SQL“int”

编辑：只是因为你可以做某事，并不意味着你应该 - 我同意Michael Haren，管理这些不太常见的数据类型的开发头痛超过你将获得的小的性能增益，除非你是处理非常高性能的软件（在这种情况下，你为什么要使用ASP.NET？）

Answer 4

如果在ASP端使用Int16，你就不会节省太多。它仍然必须最终加载到32位寄存器中。

Answer 5

仅供参考，CLR内部将int映射到Int32。

Answer 6

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

否则，SQL Server将自动对其进行上转换，或者如果需要进行下转换则抛出错误。