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:

Zitat von Bernhard Geyer (Beitrag 1321050)

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 :mrgreen:

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:

Zitat von HolgerX (Beitrag 1321049)

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:

Zitat von Captnemo (Beitrag 1321192)

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.

[Captnemo]

Zitat:

Zitat von Sir Rufo (Beitrag 1321197)

Zitat:

Zitat von Captnemo (Beitrag 1321192)

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.

Bei IBAN steht die länge fest und wird sich nicht ändern. Auch die Gruppierung der Zeichen ist noch ziemlich einheitlich.
Aber z.B. bei der Ablage von Seriennummmer oder Teilenummern gemischter Hersteller kann es oft vorkommen, dass die Gruppierung von Datensatz zu Datensatz unterschiedlich sein kann. In dem Fall kann ich die Formatierung später nicht mehr wiedergeben.
Ich kann aber für eine Suche das eliminieren der unerwünschten Zeichen für das Suchfeld dem SQL-Server überlassen, damit ich z.B. nach einer zusammenhängenden Zeichenkette suchen kann. Bei sehr großen Datenmengen und vielen Abfragen könnte man sicherlich darüber nachdenken in einem zweiten Feld den formatieren String unformatiert abzulegen um den Zeitbedarf für das Query zu minimieren. Ggf. kann das auch ein View übernehmen.

[Sir Rufo]

Bei der IBAN ist die Länge abhängig vom Land (also variabel aber über den Kontext Land und Bank kann man eine Regel ableiten).

Telefonnummern verhalten sich analog. Die unterschiedliche Formatierung bekommt man über den Ländercode, speichern würde ich die aber nur ohne Formatierung.

Bei externen Refererenz-Nummern (Seriennummern, Rechnungsnummern, Artikelnummern) speichere ich die so ab, wie ich diese für die späteren Prozesse (Bestellung, Wareneingang, Reklamation) benötige - speziell wenn diese späteren Prozesse über elektronische Verfahren wie z.B. EDI und Ähnliche laufen.

Dazu kann es notwendig sein, zum speziellen Kontext (z.B. der Lieferant) auch spezielle Regeln zu hinterlegen.

Ich habe Lieferanten kennengelernt, die für eine Artikelnummer drei unterschiedliche Schreibweisen hatten:

• Katalog (Formatierung mit -)
• Preisliste Excel (Formatierung mit Leerzeichen und - und anders gruppiert)
• Lieferschein, Rechnung, ... (unformatiert alles hintereinander weg)

Für den musste man also eine sehr spezielle Spezialregel hinterlegen, weil sonst beim Wareneingang die Leute schier verzweifelt sind.