[...] könnt ihr auch gleich BigInteger
verwenden.
Nein. Rechnen wir mal fix nach:
Integer
hat einen positiven Wertebereich bis 2^31 - 1, also [0, 2.147.483.647]. Bei einigen wenigen Statistiken und wenigen Spielern treten nach einem Jahr Überläufe auf.
Long
hat einen positiven Wertebereich bis 2^63 - 1, also [0, 9.223.372.036.854.775.807]. Man kann also sagen, dass
Long
-Statistiken (2^63 - 1)/(2^31 - 1) mal länger (bzw. ca. 2^32 mal länger) reichen als
Integer
-Statistiken, das sind 4.294.967.296 mal so viel, also reichen die 4,2 Milliarden Jahre.
BigInteger
sollte man wirklich nur dann verwenden, wenn wirklich nötig. Gründe dafür sind:
BigInteger
ist sehr, sehr langsam. Hauptgrund dafür ist der relativ komplexe interne Aufbau dieses Datentyps. Im Vergleich dazu kann eine Addition auf einem Long
von einer 64bit-CPU in einem einzigen Taktzyklus durchgeführt werden.
- Java unterstützt nativ nicht das Überladen von Operatoren, heißt also, dann man in vielen Codestellen auf die methodenbasierten Operationen von
BigInteger
zurückgreifen müsste. Sehr nervig. (Es gibt natürlich Möglichkeiten in Java auch Operatoren zu überladen, bspw. mit Manifold, jedoch bleiben alle anderen Nachteile.)
- Es ist ja nicht nur damit getan diese Daten mit
BigInteger
zu rechnen: Man müsste sie auch passend speichern. Das geht bspw. in verschiebenden Datenbanksystemen verschieden gut, ist aber natürlich auch wieder langsamer und verbraucht ggf. richtig viel unnötigen Speicherplatz.
Viel wichtiger ist die Tatsache, dass das Netzwerkprotokoll und die Darstellung in Clients eben nur 32bit-
Integer
unterstützt - wir werden also für alle Statistiken maximal
Integer.MAX_VALUE
an den Client übertragen - all der Aufwand wäre also erstmal nur für die Jahresstatistiken. Also bleiben wir doch besser bei dem, was sinnvoll ist, also
Long
