Vergabe von Schlüsselattributen

[barnti]

Hallo,

ich wollte mal eine allgemeine Frage zu der Vergabe von Schlüsselattributen stellen. Bei der Generierung dieser eindeutigen ID gibt es einen Nachteil. Handelt es sich bei dem Tabellenschlüssel um ein autoinkrementierendes Feld, wird dieser Wert evtl. schnell wachsen. Dies führt dazu dass, eine ID schnell sehr viele Stellen hat, je nach Menge der Datensätze. Damit wird es für den Menschen schwer, diese Nummer in der Realität wiederzufinden und richtig zu identifizieren. An dieser Stelle kann es zu Fehlern kommen.

Als Beispiel: Waren werden in ein System eingebucht und nach Vergabe der ID mit der erzeugten Nummer versehen und ins Lager gebracht. Handelt es sich bei dem Lager um unzugeordnete Plätze, so muss ein Lagerarbeiter ungefähr wissen wo er die Ware abgestellt hat. Anhand der Nummer kann er diese eindeutig identifizieren. Bei einer hohen Stellenzahl dieser ID kann es aber zu Fehlern kommen (Zahlendreher, etc.).

Wünschenswert wäre also eine zweite ID mit weniger Stellen, die vom Menschen schneller gelesen werden kann und damit die Fehlerrate einzuschränkt. Diese Methode setzt allerdings vorraus eine weitere ID generieren zu müssen. Damit wird man in seiner Anwendung wieder eine 'Extrawurst' bedenken (Außerdem sollte es schwer fallen 20 000 Waren mit einer 4 stelligen Zahl eindeutig zu kennzeichnen).

Wie würdet ihr ein solches Problem lösen?

Was hier nicht funktioniert:

- Eindeutige Lagerorte

[DelphiDeveloper]

Erstmal wuerde ich sagen das eine PK ID nicht dazu genutzt werden sollte,
darin sowas wie LagerortNr oder KunderNr zu sehen. Sie dient lediglich als
eindeutiges merkmal fuer die Relationen.

Es ist also imho eine eingenes Attribut. Wie dieses Attribut dann befuellt wird, haengt von der Unternehmensstruktur und Organisation ab.

Ich kann mir sehr gut vorstellen das n artikel im gleichen Lagerort liegen. Oder meinst du vieleicht eine ArtikelNr und keine LagerortNr? Selbst die ArtikelNr ist
bei mehreren Lieferungen auch nicht unique.

Erzähl mal mehr darüber was du Abbilden musst.

[barnti]

Hi,

Das Problem ist das folgende: Waren werden angeliefert. Die ware wird in das System aufgenommen und dabei werden folgende Attribute eingetragen:

SQL-Code:

Tabelle_Waren:

Waren_ID, Firma, Bestimmungsort

Anschließend soll die Ware mit der ID versehen werden und der Anlieferer übergibt die Ware + ID dem Lagerarbeiter. Dieser bringt die Ware an einen Lagerort seiner Wahl und trägt den Lagerort anschließend in das System ein. Der Lagerort ist eine Angabe wie 'Halle3' oder 'Eingang Tor4'.

Wird die Ware nun gesucht, so schaut der Lagerarbeiter an dem eingetragenen Lagerort nach und identifiziert die Ware anhand der ID. Ist dieses eine ID mit hoher Stellenzahl, so kommt es zu falscher Identifikation.

[Robert_G]

Barcodes, wären ein sehr elegantes Problem, um solche Fehler ein für alle mal aus der Welt zu schaffen.

Andernafalls, kannst du auch ein weiteres Feld hinzufügen, in dem der Typ der Ware o.ä. bestimmt werden kann.
Das sollte dann aber auch über Fremdschlüssel auf eine andere Tabelle geschehen.

[DelphiDeveloper]

Würde auch zu barcodes und handscanner tendieren, kostet ja nicht die welt das Lager mit ein paar handscanner auszustatten

[barnti]

Hi Robert,

jo, das mit den Barecodes ist im Gesrpäch allerdings überlegen wir auch 'RFID' einzuführen. Allerdings steht diese Technik noch in den Startlöchern. Datenschutzrechtlich noch fraglich...

Das mit der Fremdreferenzierung funktioniert leider so nicht, da so etwas wie Produktbezeichnungen nicht vorliegen. Meine Überlegung war die zweite ID von der ersten abzuleiten. Z.B. die letzten 4 Stellen der ID zu nutzen, wenn diese eindeutig ist. Was der Fall ist, wenn die anderen Waren bereits wieder ausgebucht worden sind.
Allerdings ist der Aufwand hoch Schlüsselattribute für jede Tabelle anders zu generieren.
Schön ware eine Lösung bei der alle Tabellen nur einen Schlüssel hätten und das Identifizierungsmerkmal unabhängig von dieser ID wäre...

[kiar]

Zitat:

Ist dieses eine ID mit hoher Stellenzahl, so kommt es zu falscher Identifikation.

wieso?

barcode wäre wohl das ideale

raik

[barnti]

@kiar

Es kommt vor, dass z.B. Zahlendreher zum Identifizieren der falschen Ware führen.

[Sanchez]

Ein Vorteil von Barcodes zu RFID sind auch die Kosten.
Unter diversen äußeren Bedingungen sind aber RFIDs besser.

Ich ärgere mich gerade über die schlechte Lesbarkeit von Barcodes unter starker Sonneneinstrahlung.

grüße, daniel

[barnti]

@sanchez

wie?Schlecht lesbar? Bleichen die Barcodes aus? Oder wie meinst Du das?

[Robert_G]

Ich meinte mit dem Fremdschlüssel eine Bestimmung des Typs der Ware.
Zum Bleistift ist die Ware ein Bleistift ( :mrgreen: ) dann kann der Bearbeiter ihn als Büroartikel und noch genauer Stift/Bleistift, oder so, ablegen.
Der nächste Mitarbeiter schnappt sich jetzt den Bleistift, watschelt zu den Büroartikeln und packt ihn in die Bleistiftschublade.
Falls jetzt etwas schiefgeht, kann man anhand des (hoffentlich vorhandenen :zwinker: ) Audit trials nachvollziehen, wenn jemand den Bleistift als Linienbus abgelegt hat.

[barnti]

Hi,

Zitat:

Ich meinte mit dem Fremdschlüssel eine Bestimmung des Typs der Ware.

Genau das geht nicht. Die Waren haben keine andere Kennzeichnung, außer der ID, der Firma und dem Bestimmungsort.

Ich muss mich leider an gewisse Beschränkungen halten. Oder habe ich Dich da falsch verstanden?

[Sharky]

Zitat:

Zitat von barnti

.... (Außerdem sollte es schwer fallen 20 000 Waren mit einer 4 stelligen Zahl eindeutig zu kennzeichnen)....

Hai barnti,

wenn ich das richtig sehe geht es Dir ja nur um eine bessere lesbarkeit der Zahlen?
Was hälst Du davon sie einfach als HEX auszugeben? Das ist meinermeinung nach für einen Menschen leichter zu lesen (da Buchstaben vorkommen) und Du kannst deine 20.000 Artikel durch 4 Zeichen darstellen ;-)

• 20.000 -> 4E20
• 41.547 -> A24B
• 999 -> 03E7

Du hast also weniger Zeichen die sich jemand merken muss und sie sind einfacher zu lesen.
UND Du kannst intern weiterhin mit den IDs der Datenbank arbeiten :stupid:

[barnti]

Hi Sharky,

Mensch das hört sich gut an. Da dran habe ich noch gar nicht gedacht! Dabei kodiere ich schon die Konfigurationsdaten meiner DB in hexadizimaler Form...

Werde ich mal durchdenken. Scheint aber eine der besten Lösungswege zu sein. Ich danke Dir!