[PHP/MySQL] Große Zahlen benutzen?

[atlan428]

Ich muss bei meinem Browsergame öfters sehr große Zahlen ins MySQL speichern. Da die Zahlen auch Nachkommastellen enthalten, habe ich die SQL-Felder als FLOAT deklariert. Dadurch können die Einträge auch richtig vom MySQL geordnet werden. Leider lassen sich jetzt keine Zahlen mehr mit PHP und den MySQL-Einträgen vergleichen.

Beispiel:

if($eingabe > $f->Goldmuenzen) {
echo "Fehler!"
}

Obwohl die Variable $eingabe den Wert 10000000000 hat und $f->Goldmuenzen den Wert 1e+03, ergibt die Abfrage das der Wert im SQL größer als der Eingabewert ist. Wenn ich das Feld aber als VARCHAR(255) deklariere, dann geht die Abfrage auch richtig. Nur das Rechnen mit dem MySQL und das Sortieren geht dann nicht mehr.

Welchen Feldtyp soll ich jetzt benutzen oder wie bringe ich dem PHP bei, dass der trotzdem mit den Werten richtig rechnen kann?

Vielen Dank für eure Hilfe!

 

[zerafin]

Welchen Feldtyp soll ich jetzt benutzen oder wie bringe ich dem PHP bei, dass der trotzdem mit den Werten richtig rechnen kann?

An der Datenbank würde ich nichts ändern. Nutz in php vor dem Vergleich einfach floatval oder intval um die Werte aus der Datenbank zu konvertieren.

edit: Der Artikel Typen-Tricks auf php.net ist sicher auch interessant für dich. Stichwort "typ-casting".

Gruß, Zera

 

[atlan428]

@ zerafin

Vielen Dank für deine sehr schnelle Hilfe! Bist du dir sicher, dass es damit richtig funktioniert? Dieses Feature ist nämlich sehr wichtig, weil gerade dieser Bug extrem ausgenutzt wurde.

 

[zerafin]

Bist du dir sicher, dass es damit richtig funktioniert? Dieses Feature ist nämlich sehr wichtig, weil gerade dieser Bug extrem ausgenutzt wurde.

Ich habe es nicht getestet, aber ich wüsste nicht wieso es nicht gehen sollte. Damit vergleichst du ja zwei Typen vom selben Typ. Zur Sicherheit könntest du noch beide verglichene Werte mit is_float überprüfen (falls zum Beispiel der Wert aus der Datenbank falsch ausgelesen wurde), aber das finde ich übertrieben.

Gruß, Zera

 

[atlan428]

Ja, dass ist klar. Jetzt stellt sich aber nur die Frage, ob die Werte auch richtig im MySQL geändert werden. Gestern war es nämlich der Fall, dass der SQL-Eintrag unverändert bleibt. Das kann bei großen Transaktionen ja sehr fatal sein.

 

[ZeroCCC]

da du nicht genau geschreiben hast um was für werte es handelt, stell ich einfach mal die datentypen double und decimal in den raum.

 

[atlan428]

@ ZeroCCC

Ich hatte doch geschrieben gehabt, welche Werte ich meine. Es handelt sich dabei um sehr große Werte (über 10 Milliarden), die auch noch bis zu 10 Nachkommastellen haben können. Welcher Datentyp ist für sowas geeignet und geht auch richtig mit PHP?

 

[ice-breaker]

float

Edit: an sonsten eben Strings und mit BCMath rechnen

 

[atlan428]

Ich benutze zur Zeit den Datentyp FLOAT. Da ist aber der Fehler aufgetreten. Man konnte die eingegebenen Wert nicht mehr mit dem SQL-Wert vergleichen und es konnten keine Rohstoffe abgezogen werden.

 

[ice-breaker]

na, dann eben nen string nutzen und mit bcmath rechnen.

 

[atlan428]

Bcmath ist auf unserem Server nicht aktiviert und ich habe auch kein Zugriff darauf. Wenn ich aber Strings im SQL benutze, dann kann man die Werte nicht mehr übers SQL sotieren lassen.

 

[ZeroCCC]

und wieso zurhölle arbeitest du mit derartigen zahlen in einem browsergame? lageweile, spaß an der freude oder wie kommt das? ich würd mir vielleicht nochmal gedanken machen ob dass so sinnvoll ist...

ansonsten nimm DECIMAL(21,10)... wird aber als string gespeichert und nicht als zahl. also mehr speicher und berrechnungen in der dv könnten auch probleme machen...

 

[atlan428]

Die großen Zahlen haben 2 Ursachen:

1. Durch die Eingabe zu großer Zahlen konnten Rohstoffe transferiert werden, die man gar nicht hatte
2. Es gibt verschiedene Benutzer, die mehr als eine Milliarde Rohstoffe besitzen

 

[ice-breaker]

Bcmath ist auf unserem Server nicht aktiviert und ich habe auch kein Zugriff darauf. Wenn ich aber Strings im SQL benutze, dann kann man die Werte nicht mehr übers SQL sotieren lassen.

häh? du erzählst doch nur PHP das die zahl als string behandelt wird. das hat doch nichts mit mysql zu tun.

@ZeroCC: warum decimal? es gibt doch bigint

 

[ZeroCCC]

häh? du erzählst doch nur PHP das die zahl als string behandelt wird. das hat doch nichts mit mysql zu tun.

@ZeroCC: warum decimal? es gibt doch bigint

bigint ist ein integer datentyp... der kann also nur mit ganzzahlen umgehen und nicht mit gleitkommazahlen. decimal ist ein ganz spezieller datentyp... intern werden die zahlen als chars gespeichert (bei neuen versionen wirds anderes codiert) somit ist eine sogut wie hunderprozente genauigkeit gegeben. jedoch erkauft man sich diese durch speicher und performance einbußen...

@atlan428 und wie kommts zu den kommastellen?

 

[ice-breaker]

bigint ist ein integer datentyp... der kann also nur mit ganzzahlen umgehen und nicht mit gleitkommazahlen. decimal ist ein ganz spezieller datentyp... intern werden die zahlen als chars gespeichert (bei neuen versionen wirds anderes codiert) somit ist eine sogut wie hunderprozente genauigkeit gegeben. jedoch erkauft man sich diese durch speicher und performance einbußen...

@atlan428 und wie kommts zu den kommastellen?

ups^^
ich habe überlesen, dass es nachkommastellen in seinem bug gibt, sry

 

[atlan428]

Es kommt zu Kommazahlen, weil man die Rohstoffe über den Martkplatz verkauft werden können und weil das Rohstoffsystem auch kleine Werte auf die Zeitdifferenz aufteilen muss.

Eisen kostet z. B. 0,219124770 Goldmünzen.

 

[ice-breaker]

da würde ich dann sagen, da ist in der Planung und Konzeption schon einiges schief gegangen
10Mrd Rhstoffe k, das darf ja sein, aber solch eine Goldmünzenzahl, nee

 

[atlan428]

Planung?

Goldmünzen gibt es natürlich nicht so viel. Ingesamt gibt es ca 5 Millionen Goldmünzen.