Zitat von
Hansa:
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.
Hmmm, ich glaube wir reden aneinander vorbei !
Die
GUID ist doch nur eine weltweit eindeutige Zahl. Ihre Benutzung ist nicht an ein Windows System gekoppelt. (Auch wenn einige Infos z.B. MAC Adr. einfliessen)
Verstehe die Zahl ainfach als das was sie ist. Eine von allem entkoppelte einmalige Zahl.
Warum willst Du diese "Zufallszsahl" ändern, wenn Du einen Rechner neu installierst?
Zitat von
Hansa:
Selbst wenns so viel wird, wieso dann mit
GUID ? Ich habe auch einen mit vielen Filialen. Jede hat eine eindeutige Nr. Wirds länderübergreifend, dann würde ich eventuell noch eine Länderkennziffer einführen. D wäre dann eben 49 und jede Filiale hätte eigene eindeutige Nr. wie gehabt.
Wenn Du in Deinen Schlüssel Länder und Filialinformationen einfliessen lässt, hast Du ja wieder einen Sprechenden Schlüssel !!! Willst Du wenn eine Firma von BRD nach Frankreich umzieht alle PKs mit der 49... ändern ?
Merke: Primärschlüssel werden NIE geändert !!!
Deshalb sollten sie keine Informationen enthalten.
Verstehe die
GUID als eine eindeutige Zufallszahl ohne weitere Informationen !!!
Zitat von
Hansa:
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.
Was Du da Kundennummer oder Artikelnummer nennst, nenne ich zusammenfassend Matchcode.
Zitat von
Hansa:
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.
hier reden wir wieder einander vorbei.
Was ist ein nicht primärer Schlüssel (oder sekundärter Schlüssel)
Auf einem
SQL-Server nennt man so etwas Index. Und ein Index wird dazu verwendet einen schnellen Zugriff auf das Feld (oder die Felderkombination) zu bekommen.
Bsp. In einer Tabelle Kunde gibt es einen PK, eine KundenNr. und den Namen.
Ich lege einen sekundärschlüssel auf Name und Kundennummer, damit ich schneller sortierenkann (order by Name) bzw auch schneller finde (where KundenNr=1234).
Allein schon aus Performancegründen finde ich also "sprechende (nicht) Primary Keys" nicht überflüssig.
(Erklärungen auch hier:
http://de.wikipedia.org/wiki/Datenbankindex )
Zitat von
Hansa:
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.
Ich verwende den Begriff Matchcode als Überbegriff für einen sprechenden (nicht primär) Schlüssel z.B. Kundennummer. Der PK der Tabelle ist zwar für den
SQL Server als "Kundennummer" ausreichend, trotzdem möchte ich eine Kundennummer zum Anfassen (und auch ändern).
Ich hoffe ich habe jetzt alle Klarheiten beseitigt
