sprechender Primärschlüssel 8)

[Hansa]

Ich bin für erhängen. :mrgreen: Besonders schlimm finde ich, da noch den string mit Sonderzeichen zu maskieren. 8) Wie soll denn das gehen, da z.B. ein ON DELETE CASCADE zu machen ? Der "Fall Mabuse" :lol: zeigt ja schön, wie man sich oder anderen das Leben schwer machen kann.

[MaBuSE]

Zitat:

Zitat von Hansa

Der "Fall Mabuse" :lol: zeigt ja schön, wie man sich oder anderen das Leben schwer machen kann.

Wobei ich betonen will, das der Kunde schon bevor ich zu diesem Projekten hinzugezogen wurde diesen Blödsinn gemacht hat. Und wenn so eine Designschwäche erst mal in einem Projekt drin ist, bekommt man sie in der Regel nicht mehr weg. (Ein Redesign will der Kunde nämlich nicht zahlen) Obwohl langfristig die Kosten ohne ReDesign höher sind. (Laufzeitverhalten, umständliche Programmierung, schlechte Wartbarkeit bei Strukturänderungen, ...)

Zusammengefasst: Im "Fall MaBuSE" bin ich unschuldig !!!

[MaBuSE]

Zitat:

Zitat von Hansa

Meiner Ansicht nach hat eine GUID in dem Zusammenhang absolut nichts zu suchen. Ganz davon abgesehen, daß sie viel zu lang ist. Deshalb wohl auch die -. Mabuse, ging es bei Dir nur um die eindeutige Identifikation eines Standortes, oder was ? Wenn ich MAC-Adressen, GUIDs usw. in der DB verbaue, dann ist man nämlich schnell wieder am Anfang !

Wenn Du einen weltweiten eindeutigen Schlüssel brauchst, kommst Du an der GUID nicht vorbei.

Wie willst Du sonst eine Syncronisation z.B. mit 1.300 SQL Server (weltweit verstreut) und ca. 50.000 Clients (die alle offline Daten erfassen können) realisieren.

Die Clients syncronisieren sich mit dem Server, die Server syncronisiersn sich gegenseitig über ein paar Duzend SQL-Server die im Cluster laufen. (Master SQL-Server in der Zentrale).

Zu GUID und 128 Bit Zahl oder String.
Nicht alle SQL-Server bieten einen GUID Datentyp an. Vor allem nicht die lokalen auf den Clients (z.B. Paradox oder DBase)

Wenn man heterogene Netzwerke hat ist das alles nicht so einfach.

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

[MaBuSE]

Zitat:

Zitat von Jasocul

Es gibt ja auch nichts gegen sprechende Schlüssel einzuwänden (an die Schreibweise muss ich mich wirklich noch gewöhnen :roll: ). Der PK sollte das aber nicht sein.
Ich benutze auch sprechende Schlüssel.

Das ist der Punkt.

Es hat niemand etwas gegen sprechende Schlüssel.
Aber eben nicht als Primärschlüssel !!!

Viele verwenden ja auch Matchcodes um einen sprechenden "Schlüssel" zu haben.
Das sind aber dann nur Sekundärschlüssel !!!

[equote="Artikel über Data-Mining im WikiPedia ( http://de.wikipedia.org/wiki/Data-Mining )"]... Ein effizienteres Verfahren stellt der Einsatz so genannter Matchcodes dar. Dieser künstliche Primarschlüssel, der anhand von wenig fehleranfälligen Zeichenfolgen aus verschiedenen Attributen gebildet wird, liefert im Allgemeinen bessere Ergebnisse und ermöglicht zugleich das Erkennen und Löschen von Doubletten. ...
[/equote]

Die Anwender in meinen Programmen bekommen nie den PK zu sehen, wohl aber den Matchcode.
Dadurch kann der Anwender die Zeile eindeutig identifizieren. In der Datenbank wird der Matchcode als Feld angelegt und automatisch gefüllt. Alle Verknüpfungen sind aber über den PK realisiert !!!

[edit]
Wenn ich hier schon den Link zum Data-Mining (s.o.) poste gibts hier auch noch einen interesannten Link zum Data Warehouseing: http://de.wikipedia.org/wiki/Data_Warehouse
[/edit]

[MaBuSE]

Zitat:

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.

Das geht aber nur, wenn Du die Kontrolle über die Clients hast.
Was ist wenn Du nciht weisst, wer Dein Programm verwendet.
z.B. öffentlicher Download des Clients im Internet.

Außerdem ist es sehr einfach eine GUID zu erzeugen. Fast jede Sprache hat mitlerweile eine Funktion zur Erzeugung einer GUID. (Nicht nur auf Windows).

Oder was ist wenn Du aus Datenschutz die Einträge anonym einsammeln willst. Also keine Länder / Filial ID haben möchtest?

Aber jetzt wirds offtopic. Eine GUID ist ja schliesslich kein sprechender Schlüssel :mrgreen:

[equote="MaBuSE schrieb in http://www.delphipraxis.net/internal...=402885#402885 "]@Hansa: Aber jetzt wirds offtopc. Wenn Du dazu eine Diskussion haben willst, machen wir gerne einen neuen Thread auf.[/equote]

[Hansa]

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

[Jasocul]

Zitat:

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.

Zum Schluß noch der Matchcode. Wozu den extra speichern ? :shock: 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.

Vielleicht sollte wir hier mal genauer unterscheiden:
Felder <> Key !
Es wir ja "nur" ein Key auf das Feld gesetzt.
Ds Zusammensetzen eines Keys bedeutet damit noch nicht, dass es ein neues Feld gibt, wo die Feld-Inhalte zusammengesetzt werden. Als zusammengesetzter Key kann das dann wieder Unique sein, aber die Felder bleiben getrennt.

Matchcode:
Benutzen wir auch bei Adressdaten. In der Firmenbezeichnung stehen of genug Daten, die du mit einem Upper und Like nicht finden kannst. Denke nur mal an Firmenabkürzungen mit und ohne Punkt/Leerzeichen. Wir legen zumindest Wert darauf, dass die Kunden so angeschrieben werden, wie in ihrer offiziellen Firmenbezeichung. Das ist aber auch die einzige Stelle, an der wir einen Matchcode verwenden.

[MaBuSE]

Ich habe hier mal was zum Lesen zusammengestellt:

Primärschlüssel:

• http://de.wikipedia.org/wiki/Prim%C3%A4rschl%C3%BCssel
• http://databases.about.com/cs/admini...primarykey.htm
• http://www.sqlteam.com/item.asp?ItemID=2599

GUID:

• http://de.wikipedia.org/wiki/GUID
• http://zdnet.de/builder/print_this.h...4665-20000202c
• http://www.microsoft.com/germany/msd...sErzeugen.mspx

Allgemein:

• http://de.wikipedia.org/wiki/Datenbank

[Hansa]

Zitat:

Zitat von Jasocul

...zusammengesetzter Key kann das dann wieder Unique sein, aber die Felder bleiben getrennt.

Jaja, so war das auch gemeint. :mrgreen: Allerdings zusammengesetzt über die IDs und nicht über die Feldinhalte. Das ist ein gewaltiger Unterschied !! Nur was soll der Matchcode ? :gruebel: Gebe ich ein : "aSOc", so würde "Jasocul" gefunden werden, aber auch "XYasocZ", also Kombination UPPER, LIKE %%. Ich überlasse es also dem User, einen Suchbegriff zu definieren, der gut ist. Der weiß schon, daß ein bloßes "a" zuviel liefert und er lange blättern, bzw. den Begriff neu eingeben muß. Sogar ein Dau merkt das zumindest nach dem 500.mal. :lol: Ich erspare ihm dadurch auch, sich außer den Nummern auch noch den genauen Mathcode zu merken.