zahl im string addieren

[himitsu]

hmmm, wenn diese "Zahlen" z.B. Nullen am Anfang hätten, sie die Int64-Grenzen sprengen würden oder sonst noch irgendwelche Formatierungen vorkommen könnten, dann wäre sowas nötig,
aber sonst wüßte ich keinen Grund dafür ... wobei ich sowas aber nie gelernt hab.

PS: mit "Integern" wäre der Speicherbedarf geringer und das Suchen geht damit schneller/besser, abgesehn von den kleineren/optimaleren Indize, auf solchen Feldern.
und du könntest problemlos damit rechnen

[khh]

Zitat von himitsu:

hmmm, wenn diese "Zahlen" z.B. Nullen am Anfang hätten, sie die Int64-Grenzen sprengen würden oder sonst noch irgendwelche Formatierungen vorkommen könnten, dann wäre sowas nötig,
aber sonst wüßte ich keinen Grund dafür.

ich sagte ja, in grauer Vorzeit, das war Speicherbedarf und Plattenplatz noch Thema NR.1

[himitsu]

aber gerade wegen meiner "großen" String-Indize (Unique-, Primary- und Foreign-Felder) in einem Projekt hatte man mich vor kurzem böse angeguckt ... das wäre also heute immernoch ein Thema

PS: stell dir mal vor du hättest eine Milliarde Artikel in deiner Datenbank, dann wären das gleich mal mehre dutzend GB

[mkinzler]

Zitat:

naja in grauer Vorzeit hab ich mal gelernt, dass Zahlen, wie z.B. Artikelnummern, mit denen (normalerweise)nicht gerechnet wird als string gespeichert werden.
Wenn ichs noch richtig weiss,war das sogar prüfungsrelevant

Zitat:

ich sagte ja, in grauer Vorzeit, das war Speicherbedarf und Plattenplatz noch Thema NR.1

Und deshalb entscheidet man sich für die Variante, die mehr Speicherplatz belegt?

[khh]

Zitat von mkinzler:

Zitat:

naja in grauer Vorzeit hab ich mal gelernt, dass Zahlen, wie z.B. Artikelnummern, mit denen (normalerweise)nicht gerechnet wird als string gespeichert werden.
Wenn ichs noch richtig weiss,war das sogar prüfungsrelevant

Zitat:

ich sagte ja, in grauer Vorzeit, das war Speicherbedarf und Plattenplatz noch Thema NR.1

Und deshalb entscheidet man sich für die Variante, die mehr Speicherplatz belegt?

siehe weiter unten, vieleicht war ja auch das der Grund

[himitsu]

Aber bei einer Alphanummerischen Artikelnummer könnte man natürlich schlecht Addieren, also scheidet hier doch dieser Grund wohl aus.

PS: man könnte auch kleinlich werden ... es heißt doch artnr und nicht artanum (oder so)

aber um's Kurz zu machen:
Wenn du nur Nummern zuläßt, dann macht sich ein nummerischer Typ natürlich besser.

[khh]

Zitat von himitsu:

aber gerade wegen meiner "großen" String-Indize (Unique-, Primary- und Foreign-Felder) in einem Projekt hatte man mich vor kurzem böse angeguckt ... das wäre also heute immernoch ein Thema

PS: stell dir mal vor du hättest eine Milliarde Artikel in deiner Datenbank, dann wären das gleich mal mehre dutzend GB

das hast du ja auf jeden Fall Recht.

Vieleicht war das damals ja auch nur die "Macke" der damaligen "Verantwortlichen", ich wies es nicht mehr.
Wobei es im Falle Artikelnummern auch hilfreich ist, falls mal ein Kunde auf die Idee kommt alphanumerische Zeichen in der Artikelnummer haben zu wollen. Dann spart man sich auf jeden Fall die Zusammensetzerei

[mkinzler]

Zitat:

Vieleicht war das damals ja auch nur die "Macke" der damaligen "Verantwortlichen", ich wies es nicht mehr.

Vermute ich auch mal. den sinnvoll ist das imho nicht.

[khh]

Zitat von mkinzler:

Zitat:

Vieleicht war das damals ja auch nur die "Macke" der damaligen "Verantwortlichen", ich wies es nicht mehr.

Vermute ich auch mal. den sinnvoll ist das imho nicht.

Allenfalls unter dem Aspekt der Alphanumerischen Zeichen, speziell in der Artikelnummer

EDIT: Zu eurer Info das waren die "guten alten" COBOL-Zeiten

[mkinzler]

Wenn auch Buchstaben erlaubt sind, dann brauchst du natürlich einen alphanummerischen Typ.