sprechender Primärschlüssel 8)

[Jasocul]

Matchcode:
Nehmen wir mal die fiktive Firma "a.t.u.". Genügt das als Gegenbeispiel? Da hilft kein Upper und kein Like. Im Matchcode stünde "atu". Da geht das dann.

Zusammesetzung aus mehreren Feldern:
Beispiel:
Ein Artikel setzt sich aus einer Kurzbezeichnung und aus mehreren Abmessungen zusammen. Da nehme ich einfach einen kombinierten Unique-Key über die entsprechenden Felder. Das hat dch mit den IDs nichts zu tun. Oder reden wir aneinander vorbei?

[MaBuSE]

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

[MaBuSE]

Zitat von Jasocul:

Matchcode:
Nehmen wir mal die fiktive Firma "a.t.u.". Genügt das als Gegenbeispiel? Da hilft kein Upper und kein Like. Im Matchcode stünde "atu". Da geht das dann.

Nennen wir den Matchcode doch in diesem Fall einfach Kundennr.
Ich habe in etlichen Programmen schon solche Kundennummern gesehen.

Es entstehen dann so "lustige" Kundennummern wie: ATU-FFM-02

[Hansa]

Zitat von MaBuSE:

...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 ?
...

Mabuse, schalte Dein Gehirn ein ! *duck* Ist ja nur Spaß. Selbstverständlich wäre auch hier kein Primärschlüssel im Klartext beteiligt !! Ich hätte eine Land-Tabelle und würde auf die ID_LAND zugreifen ! Insofern wäre eine Änderung von 49 auf 999 für alle DS verbindlich. An der ID_LAND würde sich nichts ändern. Nur an der Nr. des Landes (also Feld : Land-Nr.). Selbe Vorgehensweise gilt für Filiale. Bei mir ist das ID_MARKTNR.

Zur GUID : selbe Geschichte. Was, wenn Windows neu installiert wird ? Die GUID ist wieder eindeutig, insofern anders als vorher. Was nun ?

[Sharky]

Zitat von Hansa:

... Zur GUID : selbe Geschichte. Was, wenn Windows neu installiert wird ? Die GUID ist wieder eindeutig, insofern anders als vorher. Was nun ?

Hai Hansa,

ich glaube Du hast hier etwas falsch verstanden
Wir reden nicht von der GUID welche Windows für sich selber erzeugt hat!
Du kannst Dir ganz einfach GUIDs erzeugen. Mit diesem Code z.B. bekommst Du immer GUIDs die jeweils eindeutig sind:

Delphi-Quellcode:

uses
  ActiveX, ComObj;

function GuidToDezString (aGuid : TGuid) : String;
var
  ndx : integer;
  foo : string;
begin
  foo := IntToStr (aGuid.D1);
  foo := foo + '-' + IntToStr (aGuid.D2);
  foo := foo + '-' + IntToStr (aGuid.D3);
  foo := foo + '-';
  for ndx := 0 to 7 do
  begin
    foo := foo + IntToStr(aGuid.D4[ndx]);
  end;
  result := foo;
end;

function Neue_GuID: TGuid;
var
  guidWork: TGUID;
begin
  CoCreateGuid(guidWork);
  Result := guidWork;
end;

procedure TForm1.Button1Click(Sender: TObject);
var
  ndx : integer;
  guid : TGuid;
  sGuid : string;
begin
  for ndx := 1 to 10 do
  begin
    guid := Neue_GuID;
    Memo1.Lines.Add('Hex : ' + GuidToString (guid));
    Memo1.Lines.Add('Dez : ' + GuidToDezString(guid));
    Memo1.Lines.Add('----------------------------------');
  end;
end;

Diese GUIDs haben nichts mit meinem OS zu tun. Es sind einfach nur 128Bit Zufallszahlen.

[MaBuSE]

Zitat von Sharky:

Zitat von Hansa:

... Zur GUID : selbe Geschichte. Was, wenn Windows neu installiert wird ? Die GUID ist wieder eindeutig, insofern anders als vorher. Was nun ?

Hai Hansa,

ich glaube Du hast hier etwas falsch verstanden
Wir reden nicht von der GUID welche Windows für sich selber erzeugt hat!
...
Diese GUIDs haben nichts mit meinem OS zu tun. Es sind einfach nur 128Bit Zufallszahlen.

Das schieb ich auch schon mal:

Zitat von MaBuSE:

Verstehe die GUID als eine eindeutige Zufallszahl ohne weitere Informationen !!!

Stell Dir vor wir erzeugen eine Zufallszahl. Und wie der Zufall es will, ist diese auch noch weltweit einmalig. -> Du kannst also beliebig oft eine solche Zahl erzeugen (Code s.u.) und es wird nie (*) eine Duplette geben.

(*) http://de.wikipedia.org/wiki/GUID : Jede GUID ist praktisch einmalig. Die Wahrscheinlichkeit,dass zwei gleiche GUIDs erzeugt werden können, geht gegen null (1/(2^128) oder 1/(3.4028e38) ).


Hier ist der .net Code zum erzeugen einer GUID
(Analog sharkys Beispiel)

Delphi-Quellcode:

// Code in C#:
String MyGuid = System.Guid.NewGuid().ToString();
MessageBox.Show (MyGuid);

// Code in Delphi.NET
var
  MyGuid: String;
begin
  MyGuid := System.Guid.NewGuid.ToString;
  MessageBox.Show(MyGuid);
end;

Zitat von MaBuSE:

Ich hoffe ich habe jetzt alle Klarheiten beseitigt

Aber jetzt, oder?

[Hansa]

Ah ja, wir reden bloß über eine Zufallszahl ? Ist zwar so gut wie unmöglich, aber auch Zufälle kommen mehrmals vor. Aber egal, wer benutzt so was als Primärschlüssel ?

[Jasocul]

Die Wahrscheinlichkeit, zweimal von einem Blitz getroffen zu werden, ist auch nahezu ausgeschlossen. Aber es kommt vor.
Die Wahrscheinlichkeit, einen 128er-Code per Zufall zu entschlüsseln ist auch möglich. Da übernimmt auch niemand irgendwelche Garantien.
Ich sehe das auch so wie Hansa. Wenn ich es nicht sicherstellen kann, verlasse ich micht nicht darauf.

[MaBuSE]

Zitat von Hansa:

Ah ja, wir reden bloß über eine Zufallszahl ? Ist zwar so gut wie unmöglich, aber auch Zufälle kommen mehrmals vor. Aber egal, wer benutzt so was als Primärschlüssel ?

In dieser "Zufallszahl" ist unter anderem die MAC Adresse, Datum Zeit und eine Zufallszahl enthalten.

Es müssen dann also schon 2 Rechner die selbe MAC Adresse haben, die GUID zur selben Zeit erzeugen und dann noch genau die selbe zufallszahl erzeugen, erst dann ist die GUID zweideutig. (Wer weiß was da noch alles in die GUID einfliesst)

[MaBuSE]

Zitat von Jasocul:

Die Wahrscheinlichkeit, zweimal von einem Blitz getroffen zu werden, ist auch nahezu ausgeschlossen. Aber es kommt vor.
Die Wahrscheinlichkeit, einen 128er-Code per Zufall zu entschlüsseln ist auch möglich. Da übernimmt auch niemand irgendwelche Garantien.
Ich sehe das auch so wie Hansa. Wenn ich es nicht sicherstellen kann, verlasse ich micht nicht darauf.

Ich habe ja nicht gesagt, das man bei so einer Syncronisierug der Datenbanken kein Exception Handling benutzen sollte !!!
Wenn tatsächlich ein PK 2 mal vorkommen sollte, so muß dann aber nur einmal pro (sehr seltene Ausnahme) in die PKs eingegriffen (oder abgelehnt) werden.
Dieses Verfahren wird in der Praxis bereits tausendfach eingesetzt und funktioniert herrvoragend.

Du sagt ja auch nicht: "Ich benutze keine Ehternet, weil es dort zu Kollisionen kommt und ich meine Daten teilweise mehrfach senden muß."