PHP Fehler: String wird Long und überschreibt Werte

Verfasst am: 30. 12. 2011 [07:37]
prof_dr_dipl_ing
Dabei seit: 31.01.2011

4 Beiträge
Beitrag hilfreich?

Ich hatte selbiges Phänomen auf einem Projekt das einen Facebook-Login ermöglichte. Dabei wurde die tatsächliche "Facebook-uid" des Users durch deine genannte Zahl in die Datenbank gespeichert.

Mach aus dem Feld in der Datenbank von daher ein BIGINT statt ein INT !!! Das hatte dann mein Problem gelöst... wink.gif
 
Verfasst am: 04. 01. 2012 [17:22]
doc4pc
Dabei seit: 16.11.2009

59 Beiträge
Beitrag hilfreich?

Warum speicherst du eine Kontonummer überhaubt numerisch? Ich würde die immer als String in die DB schreiben. Schon allein wegen der möglichen Formatierungen, wie z.B. 123 1233 123 oder ähnlichem.

Oder rechnest du mit den Kontonummern: Kontonummer1 * Kontonummer2 = ????

wink.gif

LG
Andreas

Stempel bestellen beim Profi:
http://stempelprofi.de
http://stempel-kahle.de
 
Verfasst am: 04. 01. 2012 [18:04]
Ultima
Dabei seit: 09.07.2010

759 Beiträge
Beitrag hilfreich?

"doc4pc" schrieb:
Warum speicherst du eine Kontonummer überhaubt numerisch?

Weil es sonst eine Speicherplatzverschwendung wäre und die Datenbank dadurch langsamer wird.

[Dieser Beitrag wurde 1mal bearbeitet, zuletzt am 04.01.2012 um 18:05.]

 
Verfasst am: 04. 01. 2012 [22:39]
lwulfe
Dabei seit: 02.10.2009

807 Beiträge
Beitrag hilfreich?

"Ultima" schrieb:

"doc4pc" schrieb:
Warum speicherst du eine Kontonummer überhaubt numerisch?

Weil es sonst eine Speicherplatzverschwendung wäre und die Datenbank dadurch langsamer wird.

Eine Kontonummer würde ich immer als "String" anlegen. Es gibt so etwas wie den Datentyp varchar durch den die Speicherplatzverschwendung minimiert wird. Wobei eine Datenbank durch größere Datenmengen durchaus nicht langsamer wird. Da spielen andere Faktoren eine Rolle.
Wie schon Andreas meinte ist die Formatierung eines Strings leichter zu machen. Nach meinem Wissen gibt es auch Kontonummern mit führenden Nullen.

Grüße
Lutz

 
Verfasst am: 05. 01. 2012 [17:33]
doc4pc
Dabei seit: 16.11.2009

59 Beiträge
Beitrag hilfreich?


Es gibt so etwas wie den Datentyp varchar durch den die Speicherplatzverschwendung minimiert wird. Wobei eine Datenbank durch größere Datenmengen durchaus nicht langsamer wird.


So habe ich das gemeint.

MfG
Andreas

Stempel bestellen beim Profi:
http://stempelprofi.de
http://stempel-kahle.de
 
Verfasst am: 05. 01. 2012 [20:42]
Ultima
Dabei seit: 09.07.2010

759 Beiträge
Beitrag hilfreich?

"lwulfe" schrieb:
Es gibt so etwas wie den Datentyp varchar durch den die Speicherplatzverschwendung minimiert wird. Wobei eine Datenbank durch größere Datenmengen durchaus nicht langsamer wird.


Nur bringt das nicht viel, deutsche Kontonummern sind max. 10 Stellen lang. Wenn man dann noch eure Formatierung dazu nimmt sind es bis zu 14 Stellen. Ein BIGINT belegt 8 Bytes, eure Variante würde 15 Bytes belegen. Man spart also ~ 47% des benötigten Speicherplatzes pro DS.

Datenbanken werden durch größere Datenmengen langsamer, die Daten müssen schließlich eingelesen, verglichen und an den Klienten übertragen werden! Eine größere Datenmenge bedeutet immer eine größere Verarbeitungszeit.

Für die führenden Nullen gibt es das Attribut ZEROFILL.

 
Verfasst am: 06. 01. 2012 [10:42]
lwulfe
Dabei seit: 02.10.2009

807 Beiträge
Beitrag hilfreich?

Da wir jetzt schon mal bei diesem Thema sind ...
Gehen wir von max. 10 Stellen einer Kontonummer aus, können wir den Data Type char nutzen. Das spart die zusätzlichen 2 Byte von varchar.
Die Formatierung würde ich allerdings nicht mit in die Datenbank nehmen, sondern über die Anwendungsprogramme regeln. Denn eine nachträgliche Änderung der Formatierung innerhalb eines DB-Feldes kann ein enormer Aufwand sein und wäre tatsächlich Platzverschwendung.
Nun steht das Verhältnis 10:8 Byte.
Bei einer aktuellen Datenbank wird die zusätzliche Verarbeitungsgeschwindigkeit für 2 Byte selbst bei Millionen Datensätzen kaum meßbar sein.
Die Nutzung von Integer dagegen macht bei den User-Schnittstellen immer ein to_char oder ähnliches notwendig, was den Zeitvorteil wieder zunichte macht.

Grüße
Lutz

 
Verfasst am: 06. 01. 2012 [19:58]
Ultima
Dabei seit: 09.07.2010

759 Beiträge
Beitrag hilfreich?

"lwulfe" schrieb:
Gehen wir von max. 10 Stellen einer Kontonummer aus, können wir den Data Type char nutzen. Das spart die zusätzlichen 2 Byte von varchar.

Das würde in unserem Fall nichts bringen, sobald ein weiteres Feld der Tabelle vom Type VARCHAR ist wird ein CHAR mit einer Darstellungsgröße größer als 3 immer zu VARCHAR gecastet. Und in dieser Tabelle ist bestimmt noch eine Spalte diesen Types zB Kontoinhaber. Das Verhältnis wäre dann also 11:8.
Der Speicherplatz bei VARCHAR entspricht der Länge des Wertes + 1 Byte.


"lwulfe" schrieb:
Bei einer aktuellen Datenbank wird die zusätzliche Verarbeitungsgeschwindigkeit für 2 Byte selbst bei Millionen Datensätzen kaum meßbar sein.

Ja stimmt, bei einer Millionen Datensätzen wären das ja auch nur 3MB die zusätzlich verarbeitet werden müssten. Aber unsere Tabelle besteht ja nicht nur aus dieser einen Spalte und vermutlich auch nicht nur aus einer Tabelle. Die Masse der Anwendung würde dann entscheidend sein.


Gruß Thomas

[Dieser Beitrag wurde 1mal bearbeitet, zuletzt am 06.01.2012 um 20:05.]

 




Du bist nicht eingeloggt. Bitte beachte, dass Du eingeloggt sein musst, um Themen zu erstellen oder auf Beiträge zu antworten.

RSS Feed abonnieren

Werde in Echtzeit über neue Foren-Beiträge informiert:



10 Mitglieder waren innerhalb der letzten 15 Minuten online (159 heute gesamt):
Ahorn, Anthony, cdesus, ClaudiaPolenz, copudor, hillepeter, loy-webdesign, romacron, shadow31, Ultima

Administratoren und Moderatoren:
[keine]

Seitenreport hat 18123 registrierte Mitglieder, 3002 Themen und 29106 Beiträge.
Der aktuelle Mitgliederzuwachs liegt bei durchschnittlich 12 bestätigten Neuregistrierungen pro Tag.
Pro Tag werden im Seitenreport Forum durchschnittlich 1 neues Thema und 8 Beiträge erstellt.
Die Durchschnittszahlen berechnen sich aus den letzten 7 Tagen.

Mehrfach empfohlen

Seitenreport ist einer der bekanntesten SEO und Website Analyse Dienste im deutschsprachigen Raum und wurde u.a. schon empfohlen:
von Mr. Wong im Wong Letter
vom Leserservice der Deutschen Post
vom Technik Blog SiN
und vielen anderen

Partnerprogramm

12% Lifetime Provision auf alle Buchungen von Dir geworbener Mitglieder sowie 0,50 € für jede Registrierung. Eines der besten deutschen Partnerprogramme laut den appCharts von 100partnerprogramme.de. Nimm jetzt teil am Seitenreport Partnerprogramm und verdiene gutes Geld dabei!

* = Partnerlinks