我們處於處理最多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