使用Int64而不是int来代替int（C＃）
我们使用一个基本实体，它具有版本（NHibernate需要的日期时间）和guid（作为键）等属性。使用Int64而不是int来代替int（C＃）
它也有一个Id（int）字段有两个函数。首先要关联遗留应用程序密钥（如果有的话）。其次，作为一个简写代码：例如有时创建文件基于这些看起来丑陋和长期使用我们的GUID键。我的问题不是关于基础实体的利弊，而是关于将这个Id提升到Int64的问题？
它不会影响它在我们的MS SQL Server数据库中的存储方式。我们的缓存和内存会有更多的费用吗？这真的是一个担心吗？
我有兴趣听到除性能以外的其他缺点。也考虑到这些价值观可能会通过网络服务及时暴露给第三方。
另一种方法是处理大整数的异常，因为它们在派生实体中出现并实现它们。其缺点是需要在代码中完成，当我们发现生产大整数时的某些情况时，我们会做什么？当然会有输入验证来阻止实际错误，但它可能会限制扩展数据。
那么，int64使用8字节的内存存储，而int使用4字节......但是，你已经指出了大多数缺点。当然，在许多系统上执行的计算也会比较慢（64位系统运行在64位模式下可以在64位上执行与32位一样快的操作，但32位系统需要执行额外的工作，这意味着需要增加两个64位位数由两个32位加上一些额外的代码执行 - 其他数学运算将同样分解为32位操作）。但是，除非你存储了数百万个这样的数字并且执行了大量的操作，否则我怀疑你会看到任何性能差异，不管是在CPU时间还是在内存中。
可移植性...虽然如果你打算使用便携式，C＃并不是真正的通用语言，那么对于你的观点来说这可能是没有意义的？
如果你的应用程序在64位CPU上运行，那么可能没有太大的区别。
在一个32位的CPU上，一个64位的整数对于执行计算来说会占用更多的处理器资源。
还有明显的内存使用。
只有你可以回答你的缓存空间有多少关注。如果这是缓存密钥，并且你有一些巨大的值作为值，那么向密钥添加额外的4个字节不会产生太大的影响。如果全部您存储的是ID，那么显然它将具有更重要的显着效果。
此刻存储您的ID需要多少内存？
可移植性问题在哪里？我不是说没有一个人，只是对它可能在哪里感到困惑。我不能轻易想到一个没有64位整数类型的通用平台。 – 2008-10-28 11:23:49
我想说，如果所有平台都基于公共语言规范实现它们的类型，那就不应该成为问题。或者我错了？ – lowglider 2008-10-28 12:14:16