我有一个连接到存储过程的网页。在这个 SQL 数据源中,我有一个参数,我将其传递回 int 类型的存储过程。
ASP.NET似乎希望默认为int32,但该数字不会高于 6。是否可以覆盖 ASP.NET 默认值并输入 16 或者在未来的某个地方会出现冲突?
规范:数据库字段的长度为 4,精度为 10,如果这对答案有影响的话。
例如,如果您将其强制为一个字节并且该数字超过 255,则您将面临转换错误的风险(并且将引发异常)。但是,如果您知道它不会高于 6,那应该不是问题。
如果是我,我只会将它用作普通的 int,我不确定你是否可以通过将其设为一个字节来节省多少字节。抛出异常的风险太高,如果将其变小,您将失去所有好处。
坚持使用 int32。无论如何,这就是 vb 的“整数”和 SQL 的 INT。
通过使用 tinyint/byte 或 short/int16 而不是 int/int32,您不会获得任何显着的性能改进。
事实上,未来您可能会遇到的头疼问题是您可能必须为期望 int32 的对象执行所有强制转换,这会让您发疯。
当您说 DB 字段的长度为 4 时,这意味着 4 个字节,相当于 Int32(4 个字节 = 32 位)。这就是为什么您的列作为 int32 返回的原因。
SQL Server 中有不同的整数数据类型——如果你确定数字不会超过 6,你应该将数据库中的列声明为“tinyint”,它使用单个字节并且可以保存从 0 到255. 然后 SQL 数据源应将其转换为“字节”数据类型,这对您的目的来说是可以的。
CLR "byte" == SQL "tinyint" (1 字节) CLR "Short" (或 int16) == SQL "smallint" (2 bytes) CLR "int32" == SQL "int"
编辑:仅仅因为你可以做某事,并不意味着你应该——我同意Michael Haren的观点,管理这些不太常见的数据类型的开发头痛超过了你将获得的少量性能提升,除非你正在处理非常高性能软件(在这种情况下,您为什么要使用 ASP.NET?)
在 ASP 端使用 Int16 并没有节省多少。它最终仍然必须将其加载到 32 位寄存器中。
仅供参考,无论如何,CLR 在内部都将 int 映射到 Int32。
使用您的SQL Server存储过程定义的任何内容。如果它int
在 SQL Server 中,则在 .NET 中使用 Int32。SQL 中的 smallint 是int16
.
否则,SQL Server 将自动对其进行上转换,或者在需要下转换时抛出错误。