0

はい、同じ質問をした人が他にもいることは知っていますが、この場合、彼らの解決策はうまくいきません。

これが私の問題です。

非常に多数の整数を合計しています。実際には、SUM 関数が機能しないほど多くあります。

だから私はこれを行います：

Sum(cast(LotsofIntegers as decimal)) は私に 3472201304 を与えます

これを hh:mm:ss で表示したい。問題は、Dateadd 関数がそのような大きな数を受け入れないことです。そうでなければ、私はこれを行うことができました

CONVERT(VARCHAR,DATEADD(ms,Sum(cast(LotsofIntegers as decimal)),0),114)

これが一般的な解決策です。

たくさんの分割を使ってこれを非常に難しい方法で行う必要はありません。

誰でも手伝ってもらえますか?

4

1 に答える 1

0

これを試してください（MySQL構文。選択したRDBMSに変換してください）：

SELECT CONCAT( 
    CAST((@hours := FLOOR(SUM(msec)/3600000)) AS CHAR), 
    ":", 
    CAST((@minutes := FLOOR((SUM(msec) - @hours * 3600000) / 60000)) AS CHAR), 
    ":", 
    CAST((@seconds := FLOOR((SUM(msec) - @hours * 3600000 - @minutes * 60000) / 1000)) AS CHAR)
) FROM my_table WHERE 1;

合計が 25,000,706,152 の 5,000,001 行のテーブル (64 ビット演算で) で、正しい答えは6944:38:26です。

問題は、最も一般的な RDBMS の日付差クラス (使用していると思われる MSSQL を含む) が2^32、4 バイトの内部表現のためにミリ秒単位の差しかサポートできないことです。これは問題の RDBMS の制限です。明らかに、一度に 40 億ミリ秒を超える処理を行うことは、想定されたユース ケースの範囲外でした。残念ながら、組み込み機能を拡張するためのパッチがリリースされない限り (または、私が聞いたことのないアップグレードされた機能が存在します!)、それを行うには長い道のりが必要です。

于 2012-08-16T06:44:49.513 に答える