我发现了一些有关此问题的话题。即使字节或smallint可以处理数据，除非它是移动应用程序，否则大多数人似乎更喜欢在整个C＃代码中使用int。我不明白为什么。将C＃数据类型定义为与数据存储解决方案中相同的数据类型是否更有意义？
我的前提：如果我使用类型化的数据集，Linq2SQL类，POCO（一种或另一种），如果我不使我的数据类型在各层之间保持同步，则会遇到编译器数据类型转换问题。我真的不喜欢做System.Convert，只是因为在C＃代码中使用int更容易。我一直使用所需的最小数据类型来处理数据库以及代码中的数据，以保持与数据库的接口整洁。因此，我敢打赌我的C＃代码中有75％是使用字节或短整数而不是整数，因为这就是数据库中的内容。
可能性：这是否意味着大多数只将int用于代码中所有内容的人也将int数据类型用于其sql存储数据类型，并且可能不太在乎数据库的整体大小，还是在适用的情况下对代码进行system.convert？
我为什么在乎：我永远都在工作，我只想熟悉最佳实践和标准编码约定。
在性能方面，几乎在所有情况下int都更快。CPU被设计为以32位值有效工作。
较短的值很难处理。例如，要读取单个字节，CPU必须读取包含该字节的32位块，然后屏蔽掉高24位。
要写入一个字节，它必须读取目标32位块，用所需的字节值覆盖低8位，然后再次写回整个32位块。
当然，从空间角度来看，您可以使用较小的数据类型节省一些字节。因此，如果您要构建一个包含几百万行的表，那么较短的数据类型可能值得考虑。（这也许是为什么应该在数据库中使用较小的数据类型的一个很好的理由）
从正确性上讲，int不会轻易溢出。如果您 认为 您的值将适合一个字节，然后在将来的某个时候对代码进行一些无害的更改，意味着将更大的值存储在其中，该怎么办？
这些就是为什么int应该是所有整数数据的默认数据类型的一些原因。仅当您实际要存储机器字节时才使用字节。仅在处理实际指定16位整数值的文件格式或协议或类似格式时，才使用短裤。如果您通常只处理整数，则将它们设置为整数。
