Ablage langer Zahlen

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

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

[Sir Rufo]

Zitat von Captnemo:

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.

Nein, immer so abspeichern, damit die Bedeutung erhalten bleibt (zur Not cleanen, falls das mit der Formatierung eingegeben wurde).

Beispiel IBAN

Code:

formatiert: DE32 3456 5643 4564 4543
speichern: DE323456564345644543

Bei einer Suche erfolgt der Zugriff einmalig auf diesen Char-Wert, dann hat man die interne ID und dann wird damit weiter gearbeitet.