我们处于处理最多15位数字的情况。我们需要从文本文件解析这个值，通过C，将它存储在Informix表中。还有另一个Java组件读取这些值，进行数学运算并计算结果。处理巨大的数字C，Java，Informix
我一直在做这方面的一些研究，发现通过的Informix提供的数据类型int8的将是C.
的合适人选。关于Java的，我打算使用BigInteger类。
采取这种方法是否存在任何缺陷。任何想法都表示赞赏。
只是为了您的信息，这是一个旧的应用程序，它一直在使用基元到目前为止。而且它只能处理原语范围内的数字。
谢谢。
只要你所有的数字（包括计算）都保持在15位以下，一个长基元是一个完全有效的选择，它具有性能和运算符的优点。 BigInteger的缺点确实在于必须始终使用方法时的冗长/困难（在Java中没有运算符重载，并且唯一对某个对象起作用的运算符是用于字符串连接的+）。
就性能而言，如果不了解更多关于应用程序的信息，我不能说，但第一个假设应该是，直到您测量为止，才可以使用BigInteger。
如果我理解正确，读取“小”值（适合于INT8 integers），然后在Java中进行计算，从而得到“大”值作为结果;对？
只要您不尝试将BigInteger值挤入INT8数据类型，它对我来说看起来很好。由于Stephen C已经指出，Java的long类型也有64位宽度，所以这也可能是合适的。
如果您的“巨大”数字最多为15位十进制数，那么long可能是一个选项。 Java long类型的范围为-2**63 to +2**63 - 1。而2 ** 63是19位十进制数字......如果我可以计数:-)。
如果当然，如果您的计算的任何中间结果是19位或更多，long将不起作用，您可能需要使用BigInteger。
使用BigInteger没有特别的缺陷，只是它们比原始整数类型慢得多......而且更详细。的确，它们的优点是不必担心整数溢出。
在C（C99，具体而言）中，long long类型是一个64位带符号的二进制整数，因此它最多可以保存18位数字。
在Java中，long类型是等效类型，即64位带符号的二进制整数。
你是正确约很长很长，但在检索（上DB）从INT8类型的数据，并试图将它长长分配给它会不会产生兼容性问题？ – prabhu 2009-10-15 09:15:37
如果您只是使用C从文本文件中解析这些值，然后将它们运送到其他地方，则应该能够将它们保留为字符串。如果不进行自己的翻译，您将无法进行任何类似数学运算的操作，但是从您的描述中不必进行。
有在花时间没有找到点的二进制表示，或可对这些数字做数学库，如果所有他们是C程序的15位字符串。
如果您的Informix版本支持BIGINT和BIGSERIAL，优先于INT8和SERIAL8使用它们。由于各种复杂的原因，INT8和SERIAL8实际占用磁盘上的10个字节; BIGINT和BIGSERIAL支持相同的值范围，但只占用磁盘上的8个字节。
如果您的Informix版本不支持BIGINT和BIGSERIAL，考虑升级到IDS 11.50。
如果Informix JDBC驱动程序仅支持INT8，然后使用INT8反正。
谢谢。我们正在使用IDS版本10.00。猜测我们将不得不忍受INT8直到我们考虑升级。我认为IBM将于2010年9月底停止对该版本的支持。 – prabhu 2009-10-15 06:06:43
@Prabhur：这听起来像是一个合理的服务终止日期。 – 2009-10-15 14:51:40
“你看过‘小’值（适合8位整数），然后让在Java中计算你在哪里得到‘大’值作为结果;对” 不是。我也可能读大数值。它可以扩展到15位数字。是的，我不会不惜一切代价去挤压它。 – prabhu 2009-10-14 13:49:22
哦，对不起，我认为int8是8位整数。固定的答案... – foraidt 2009-10-14 14:06:57