zahl im string addieren

[khh]

hallo zusammen, ich möchte eine Artikelnummer die in einem char-feld gespeichert ist um 10000 erhöhen.

Code:

update artikel set artnrneu  = (artnralt  + 10000);

funktioniert leider nicht.
Auch alle diversen versuche mit cast as o.Ä. schlugen fehl

ist sicher ganz einfach. oder ?

[DeddyH]

Die Artikelnummer ist aber immer nummerisch, obwohl sie als String gespeichert wird?

[edit] Das hier hat bei mir funktioniert:

SQL-Code:

UPDATE
  Artikel
SET
  ArtNr = CAST(CAST(ArtNr AS INTEGER) + 10000 AS CHAR(8))

[/edit]

[mkinzler]

Ich würde das dann auch mit einem numerischen Typ speichern

[khh]

Zitat von mkinzler:

Ich würde das dann auch mit einem numerischen Typ speichern

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


ich danke euch

[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 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

[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