Ablage langer Zahlen

[KPBecker]

Hallo, Delphi-Praktiker,

gegeben: Material-, Bestellnummern und Ähnliches mit 6, 8 10 Stellen in einer DB.
Frage: Ablage als Zahl (integer) oder String zu empfehlen?

Es kommen nur Ziffern vor, mit diesen "Zahlen" wird nicht gerechnet, Definition als Index häufig.

Vielen Dank für einen Tipp,
Klaus-Peter

[HolgerX]

Wenn Du mit SQL danach suchen musst, dann lieber als integer, diese Datentyp kann vom Datenbank-Server besser indixiert und somit durchsucht werden.

Ein String ist da immer langsammer.

[Bernhard Geyer]

Lass dir das schriftlich geben das es nur Zahlen mit 6-10 Stellen sind die auch nicht (relevante) führende 0en haben (Also ein 0004711 nichts anders ist als ein 04711).
Bei vielen Firmen sind Material/Bestellnummern länger als 10 Stellen und beinhalten auch Buchstaben.

[Sir Rufo]

Zitat von Bernhard Geyer:

Lass dir das schriftlich geben das es nur Zahlen mit 6-10 Stellen sind die auch nicht (relevante) führende 0en haben (Also ein 0004711 nichts anders ist als ein 04711).
Bei vielen Firmen sind Material/Bestellnummern länger als 10 Stellen und beinhalten auch Buchstaben.

Ich würde es mir auch bestätigen lassen und das Feld trotzdem als char anlegen

Und ich unterscheide auch immer nach der internen und externen Referenz

Code:

Orders
  Id INT PRIMARY IDENTITY // interne Referenz
  Ref VARCHAR(20) UNIQUE INDEX // externe Referenz
  ...

Bei einer Suche gibt es einen Zugriff auf die Referenz und ab da geht dann alles über die Id weiter.

[BUG]

Wenn du nicht gerade Bereichsabfragen darauf machen möchtest, würde ich es aus vermeiden, die "Zahlen" als Integer zu speichern.
Denn eigentlich sind es keine Zahlen, sondern Bezeichner. Gerade wenn du die Dinger nicht selbst erstellst, schleicht sich da gerne mal ein Buchstabe ein, oder es ist sind doch ein paar Ziffern mehr. Wenn du dann alles auf Integer ausgerichtet hast, guckst du in die Röhre.

Für wahlfreien Zugriff gibt es Hash-basierte Indices. Wenn es Platzprobleme gibt, musst du den Produkten/Materialien/... als Primärschlüssel halt zusätzlich eine interne ID verpassen.

[Dejan Vu]

Zitat von HolgerX:

Wenn Du mit SQL danach suchen musst, dann lieber als integer, diese Datentyp kann vom Datenbank-Server besser indixiert und somit durchsucht werden.

Ein String ist da immer langsammer.

Entschuldigung, das ist viertrangig. Was heißt überhaupt 'besser indexiert'? Willst Du im Ernst behaupten, das Du einen Unterschied messen kannst, zwischen einer Zahl und einem varchar(10) Datentyp? Wir leben im Jahr 2015, da ist das so was von egal.

Kurz geschätzt: Ein B-Baum hat bei 100 Mio Einträgen und einem 100er key bei einer Seitgröße von 8k eine Tiefe von ca. 5 Ebenen. In jedem Blatt sind ca. 60 Keys gespeichert. Ich bin nach ca. 40 Vergleichen am Ziel (5x Binärsuche in einer Liste mit 60 Schlüsseln).

Ein B-Baum mit einem INT- Key hat eine Tiefe von ca. 3 Ebenen, bei vielleicht 1000 Keys pro Seite/Blatt. Das sind dann 30 Vergleiche.

(Hoffentlich habe ich mich nicht komplett verrechnet)

Wer Artikelnummern als Zahl anlegt, der macht einen riesen Fehler. Spätestens Übermorgen soll doch eh umgestellt werden (Murphy rules).

Ich hatte erst 7-Stellige (bei einem DAX-Unternehmen), dann 8, aber immer numerisch. Und dann -letztendlich- doch fast numerisch. Also 12 der 14 Stellen waren schon Ziffern. Nur die blöden Verpackungscodes in der Mitte nicht. Mist.

Leg das als char/varchar(X) an, wobei X noch ein wenig Luft nach oben lässt (nun aber nicht 1000 oder so). Dann bist Du auf der sicheren Seite. Und ignoriere die premature Optimization Profis.

[KPBecker]

Hallo, Delphi-Praktiker,

vielen Dank für die schnellen Antworten, die Sache stellt sich ja eindeutig dar.

Zusatzfrage in Bezug auf das "bißchen Luft nach oben":

Würdet ihr das DB-Feld dann grundsätzlich links mit Blank oder Nullen auffüllen, um Rechtsbündigkeit zu erreichen?
(Sortierung, Lesbarkeit, ...)

Klaus-Peter

[Dejan Vu]

Nein. Niemals. Wozu auch?
1. Gebot: "Verfälsche niemals die Daten"
2. Gebot: "Ein Datum erfüllt genau einen Zweck".

Wer sagt Dir, das 010101 nicht doch nach 020101 angezeigt werden soll (weil 01 die Muttern sind und 02 die Schrauben und der Chef einfach will, das Schrauben oben sind).

Wenn Du eine totale Ordnung auf deinen Artikelnummern aufbauen willst, dann führe eine separate Sortierspalte ein. Dort kannst Du dann die Ordnung aufbauen.

Weiterhin würde ich mich sowieso niemals auf irgendwelche Kodierungen verlassen, d.h. z.B. darauf schließen, das die ersten beiden Stellen der Artikelnummer immer die Materialgruppe definieren. Blödsinn: Ändert sich sowieso irgendwann.

[Luckie]

Generell: Daten so speichern wie sie rein kommen und im Original aussehen. Rechtsbündigkeit, auffüllen, damit es besser aussieht, gehört in die Darstellung, wenn die Daten dem Benutzer präsentiert werden.

Wenn du sie geschönt in der DB abspeicherst und brauchst sie im Original. Was dann? Wo wurde wie geschönt? Big problem.

[Captnemo]

Gerade bei Material, Bestellnummer o.ä. würde ich immer Char den vorzug geben.
1. Weiß man wirklich nie, ob sich Regeln wie "Beinhaltet nur Ziffern", auch wenn sie zur Zeit Gültigkeit haben, nicht doch irgendwann mal ändern (oder ändern müssen).

2. (obwohl ich nicht weiß, ob das mal einen Unterschied machen kann) man doch eh bei Suchen auch mal über ein Like eine Auswahl treffen will.

3. Gerade solche Nummern werden gerne in gut lesbaren Zifferngruppen dargestellt, dabei kann sich die Möglichkeit diese Formatierung auch abzuspeichern manches Mal als nützlich erweisen.