Ist die Zuordnung der Daten egal, oder sogar anonym, dann wäre das mit
GUID vielleicht gut so. Aber ich kann mir nicht vorstellen, daß so was in einer Firma mit vielen Filialen geht. Ich hätte jedenfalls keine Lust, mir bei hardwarebedingten Windows-Neuinstallationen usw. die halbe Datenbank wegen anderer
GUID umzuspeichern. Genau solche Fälle sind doch der Grund für IDs usw. Nämlich das entkoppeln der Daten vom Zugriffsmechanismus.
Bspw. Art.-Nr. oder Kunden-Nr. war bei mir schon immer ein normales Feld. Intern werden die Verknüpfungen allerdings über IDs realisiert. Man stelle sich mal vor, aus irgendwelchen Gründen muß die Ku.-Nr. geändert werden ! Wie Mabuse schon sagt : an die PKs kommt sowieso keiner dran.
Und sprechende (nicht) Primary Keys finde ich auch überflüssig.
IMHO sollte man zusammengesetzte benutzen, aber keine im Klartext ! Zumindest bei mir siehts so aus, daß ich z.B. für einen Preis, den Key zusammensetze als ID_KUNDE + ID_ART und dann natürlich als unique. Ich könnte ihn auch eindeutig machen durch Kunde.Nr + Art.Nr, aber dann wäre ich wieder in dem Dilemma, falls sich eine Nr. ändert.
Zum Schluß noch der Matchcode. Wozu den extra speichern ?
Das sind dann Redundanzen und die sollte man vermeiden. Hinzu kommt dann noch ein Problem. Entweder er wird so abgekürzt, daß ein Dritter gar nicht drauf kommt, oder er ist so lang, daß auch der kleinste Schreibfehler dazu führt, daß nichts gefunden wird. Und ich habe trotz UPPER,%LIKE% usw. noch keine Performance-Einbußen bemerkt.