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

lenim 发布于 2018-04-29 asp.net 最后更新 2018-04-29 16:46 199 浏览

我有一个连接到stored procedure的网页。在这个SQL数据源中,我有一个参数传回给int类型的存储过程。 ASP.NET似乎要默认为int32,但数字不会高于6.可以重写ASP.NET默认值并放入16位,否则会在某处出现冲突? 规范:数据库字段的长度为4,精度为10,如果这在答案中有所不同。

已邀请:

yut

赞同来自:

如果你强制它是例如一个字节,并且数字超过了255,你可能会面临转换错误的风险(并且会抛出异常)。但是,如果你知道它不会高于6,它应该不成问题。 如果是我,我只是将它作为一个普通的int使用,我不确定如果通过将其作为一个字节来节省多少字节以外的其他东西,那么可以节省很多。抛出异常的风险太高,并且通过使其更小而失去所有好处。

sea

赞同来自:

坚持与int32。无论如何,这就是vb的“Integer”和SQL的INT。 通过使用tinyint/byte或short/int16而不是int/int32,您不会获得任何显着的性能改进。 事实上,由于所有可能需要为需要int32s的对象执行的演职工作所导致的未来可能遇到的麻烦,都会让你发疯。

iut

赞同来自:

当你说DB字段长度为4时,这意味着4个字节,相当于一个Int32(4字节= 32位)。这就是为什么你的列被作为int32返回。 SQL Server中有不同的integer datatypes - 如果您确定该数字不会高于6,则应该将数据库中的列声明为“tinyint”,它使用单个字节并可以保存0到255之间的值然后SQL数据源应该将其转换为“字节”数据类型,这对你的目的来说很好。 CLR“byte”== SQL“tinyint”(1字节) CLR“Short”(或int16)== SQL“smallint”(2个字节) CLR“int32”== SQL“int” 编辑:只是因为你可以做点什么,并不意味着你应该 - 我同意Michael Haren,管理这些不常见的数据类型的开发头痛胜过你将获得的小的性能收益,除非你正在处理非常高性能的软件(在这种情况下,为什么你会使用ASP.NET?)

et_est

赞同来自:

通过在ASP端使用Int16,你不会节省很多。它仍然必须最终将其加载到32位寄存器中。

modit

赞同来自:

仅供参考,CLR在内部将Int32映射到Int32。

tqui

赞同来自:

使用SQL Server存储过程定义的任何内容。如果它是SQL Server中的int,则在.NET中使用Int32。 SQL中的smallint是int16。 否则,SQL Server会自动上转换,或者如果需要下转换,会引发错误。