Alphanumerisches Schlüsselfeld

[Frank Schäfer]

Hallo,

ich arbeite gerade an einer Artikeldatenbank mit Delphi 5 und Interbase 6. Ich habe hier ein Problem mit dem richtigen Datentyp für die Schlüsselfelder. In den meisten Büchern über Datenbankprogrammierung wird für den Primary-Key ein Integer-Feld empfohlen. Nun will ich die Anwender aber nicht in der Wahl ihrer Artikelnummern beschränken. Zudem soll auch die EAN genutzt werden können. Die EAN kann jedoch entweder 8 oder 13 Stellen haben, eine Erweiterung auf 14 Stellen ist geplant. Ausserdem kann die EAN mit '0' bzw. '00' anfangen. Hiermit fällt ein Integer schon aus der Planung, da es die führenden Nullen abschneiden würde.

Ich denke hier hilft mir nur ein Textfeld weiter, auch wenn es nur mit Zahlen belegt wird. Hierbei habe ich dann aber das Problem, das Texte anders sortiert werden. Es wäre z. B. die Nummer '1234567890123' vor der Nummer '99999999'. Ein Ansatz richtig zu sortieren ist, die Zahlen bei Eintrag in die Datenbank mit führenden Leerzeichen auf eine einheitliche Länge (Feldlänge) zu bringen. Somit wird zwar richtig sortiert, jedoch die Suche nach einer Nummer wird erschwert, sobald nicht alle Nummern die gleiche Länge aufweisen.

Es ist zwar kein Problem, einen Artikel mit bekannter Nummer aufzurufen - einfach wieder die notwendige Anzahl Leerzeichen voranstellen - aber wie Suche ich nach Artikeln die mit '123' anfangen. Wie viele Leerzeichen stelle ich voran.

Wer hat so ein Problem schon einmal wie gelöst? Sollte ich Zwei Felder anlegen, eines zum Sortieren mit führenden Leerzeichen, das Andere für die Suche linksbündig? Gibt es vielleicht andere Datenbanken, die soetwas über Index lösen?

Bitte helft mir.

Gruß, Frank

[Kai Möller]

Hallo Frank,

ehe DU schreckliche Klimmzüge machst, nimm ein Varchar Feld.

Nachteile gegenüber einem gleichlangen Integer ergeben sich nicht, auch wenn der Integer DB-intern etwas platzsparender ablegegt werden sollte.

Ka

[Andreas Kosch]

Hallo,

wenn dieser Primärschlüssel der Tabelle auch als Fremdschlüssel in anderen Tabellen (referenzielle Integrität) verwendet werden soll, würde ich trotzdem eine INTEGER-Spalte als Primärschlüssel verwenden. In den meisten Fällen ist es nicht sinnvoll, irgendwelche "Fachinformationen" im Primärschlüssel unterzubringen, so dass ich diese Informationen aufteilen würde: <br>
1. Spalte: INTEGER als Primärschüssel <br>
2. Spalte: Artikelnummer (beliebiger Datentyp)<br>
Somit bleiben die Vorteile des schnellen INTEGER-Typs erhalten, ohne Kompromisse bei der Artikelnummer eingehen zu müssen. Der Primärschlüssel in einer SQL-Datenbank hat nur die Aufgabe, einen eindeutigen logischen Zugriff auf jeden einzelnen Datensatz anzubieten. Und dazu reicht ein INTEGER-Feld mit beliebigen Nummern aus. Alles andere wird über die sonstigen Möglichkeiten der SQL-Datenbanken (UNIQUE INDEX etc.) abgedeckt.
&#10

[Kai Möller]

Andreas,

in diesem Fall braucht man aber zwei Indexes, einen für den Primärschlüssel und einen für den Zugriff auf die Artikelnummer.

Wenn das Datenmodell nicht sehr komplex und der vorhandene 'fachliche' Char-Schlüssel nicht zu lang ist, würde ich diesen gleich als Index verwenden

[Frank Schäfer]

Hallo Kai, Hallo Andreas,

vielen Dank für eure Antworten. Leider hilft mir dass bei meinem grundlegenden Problem nicht weiter.

1. Ob ich nun ein Char- oder Varchar-Feld anlege, wenn ich nach dem Feldinhalt sortiere, kommt es nicht in der Reihenfolge der Werte, sondern als sortierter Text (1000 vor 999).

2. Selbstverständlich kann ich noch ein weiteres Integer-Feld als Primärschlüssel anlegen. Nur hilft mir dass ebensowenig. Ich kann auch damit weder nach der Artikelnummer sortieren noch suchen.

In der Praxis stelle ich es mir auch etwas schwierig vor dem Kunden begreiflich zu machen: "Die 12345 ist deine Artikelnummer und den Artikel rufst Du mit der 1326 auf!" Ausserdem gibt es schon genug Nummern. Es geht auch nicht nur um den Primärschlüssel, sondern obige Probleme habe ich bei einem Artikeldatensatz z. B. mit den Feldern Artikelnummer, Lagerfach, Lieferant, Lieferantenartikelnummer, Type, etc..

Folgende Beispiel-Anforderungen werden immer wieder an den Inhalt obiger Felder gestellt:

- zur Inventur eine Artikelliste nach Lagerfach
- zur Preispflege eine Artikelliste nach Lieferant und Lieferantenartikelnummer oder Lieferant und Type
- Artikelsuche nach Artikelnummer, EAN oder Lieferantenartikelnummer

Alle diese Felder können heute kein Integer-Wert mehr sein, weil die Kunden aussagefähige Bezeichnungen wollen, oder wie bei der Lieferantenartikelnummer gar keinen Einfluss auf den Inhalt haben.

Wie kann ich also mehrere Felder wahlweise mit Integerwerten oder mit Zahlen belegen, entsprechend sortieren und leicht wiederfinden. Meine Erfahrungen mit einer Navision-Datenbank zeigen, dass dies funktionieren kann, ich weiss nur nicht wie die das lösen (warscheinlich über spezielle Index-Verwaltung

[Kai Möller]

Hallo Frank,

Es handelt sich wohl um eine komplexere Anwendung. In diesem Falle solltest Du einen künstlichen Schlüssel, wie von Andreas vorgeschlagen, für die Tabelle verwenden. Für jedes 'echte' Such- oder Sortierfeld benötigst Du dann allerdings einen weiteren Index. Der Anwender oder Kunde braucht den künstlichen Schlüssel ja nie zu Gesicht bekommen.

Gegen das Sortierproblem 1000 vor 999 hilft nur, führende Nullen immer mit abzuspeichern, evtl. automatisiert über eine Delphi-Function oder sogar einen Interbase-Trigger auf DB-Ebene