PHP Fehler: String wird Long und überschreibt Werte (Seite 2)

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 = ????



LG
Andreas

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

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

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

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

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.

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

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