sprechender Primärschlüssel 8)

[Hansa]

Das hier ist Mabuses Schuld. :mrgreen: Aber es interessiert mich, ob so was immer noch Gang und Gäbe ist. Also : wie siehts aus, ohne ID ? Wer macht so was ? Ich kann ja noch verstehen, wenn einer bei Textilien eine "sprechende Art.-Nr." verwendet. Aber beim Primary Key hörts doch wohl auf. 8)

[WoGe]

Hallo,

niemals ohne ID, hatte ich hier auch schon mal gesagt.
Unter gewissen Bedingungen, wie z.B. nur ein Messgerät könnte man noch einen Timestamp akzeptieren. Aber wie ich aus praktischer Erfahrung gelernt habe ist auch das schon fragwürdig.

mfg
wo

[r_kerber]

Ich kenne ein System, da war der PK ein zusammengesetzter Schlüssel, teilweise sogar mit VARCHAR-Spalten. War zwar sehr sprechend, IMHO aber auch eine Performance-Bremse.

[MaBuSE]

Zitat:

Zitat von Hansa

Das hier ist Mabuses Schuld. :mrgreen:

Danke :roll:

Ich kenne mehrere Systeme die sprechende Primärschlüssel haben.

Das Beispiel mit den Datum habe ich ja schon gepostet.
Das "Datenmodel" war schon "fertig" als wir in das Projekt einstiegen.
Leider gab es keine Möglichkeit das wieder geradezubiegen.
Das Projekt hatte über 300 Tabellen davon waren über 80 mit diesem sprechenden Schlüssel.

Wenn ein Termin verschoben wurde, musste in allen 80 Tabellen der Schlüssel geändert werden.

Da das ganze anfangs auf der BDE mit Paradox Dateien aufbaute und erst später nach Sybase SQL Server und danach auf MS-SQL Server portiert.
auf dem SQL Server gab es wenigstens die Möglichkeit das Ganze in eine StoredProc zu packen.

(Fast alle PKs waren sprechende Schlüssel, aber dieser war besonders schlimm!)

Anderes Beispiel:

In einer Anwendung zum Wertpapiergeschäft gab es einen sprechenden Schlüssel mit der WKN.
Es hatte niemand damit gerechnet, das die WKN (Wertpapiernummer) durch die ISIN abgelöst wurde.
So mussten die ganzen Schlüsselfelder erweitert werden um die längere ISIN aufzunehmen. Außerdem mussten neue Felder mit der "alten WKN" angelegt werden.
Ich hätte lieber gleich eine fortlaufende Nummer als Primärindex genommen und die ISIN und WKN als Matchcode in 2 weitere Felder abgelegt.

Die zu verwaltenden Fonds waren natürlich auch als sprechende Schlüssel angelegt :?
(so konnte man direkt ohne Verknüpfung mit anderen Tabellen select Statements ausführten, die den Fonds oder die WKN selektierten. Das war die offizielle Begründung)

Ich könnte noch einige Beispiele mehr nennen, (unter anderem auch in Fachkreisen bekannte Programme) die solche sprechenden Schlüssel haben :?

Ach ja, die Programme sind immer noch im Produktiven Einsatz, auch wenn ich Sie (zum Glück) nicht mehr betreue.

[Jasocul]

Ich benutze grundsätzlich eine ID als PK. Auch bei Tabellen, wo man davon ausgehen sollte, dass es nicht erforderlich ist. Wie man Mabuses Beitrag sieht, ist das durchaus sinnvoll.

Aber wenn man Altlasten übernehmen muss, ist man halt in den A... gekniffen.

P.S.: Warum steht das unter K&T? Gehört das nicht in Datenbanken?

[MaBuSE]

Zitat:

Zitat von Jasocul

Ich benutze grundsätzlich eine ID als PK.

Meinst Du mit ID einen Integer oder eine GUID

Ich habe auch schon mit Systemen gearbeitet in denen alle Primärschlüssel so aussahen:

Code:

c2755174-b4f7-4662-85b2-8579c851d48b

Also eine GUID.
Da diese weltweit einmalig ist, kann man relativ leicht Syncronisationen von mehreren dezentral laufenden SQL Servern durchführen. Die PKs sind ja weltweit einmalig, also können Datensätze einfach "hinzukopiert" werden.
Zu jedem Datensatz wird noch eine Timestamp gespeichert, dann kann man mit

SQL-Code:

insert into TABELLE from
select * from TABELLE@REMOTEHOST
where TIMESTAMP_FIELD > :TIMSTAMP_OF_LAST_SYNC

einen Abgleich starten.

Dumm nur, das eine GUID im VARCHAR2 oder CHAR nicht so performant ist wie ein Integer :?

[edit]
Das macht aber auch z.B. Sinn wenn die Clients auch offline Daten erfassen können, die dann erst mal lokal gespeichert werden und später mit dem Server syncronisiert werden.
[/edit]

[ibp]

sicherlich ist es sinnvoll entititäten zu benutzen. je nach situation spricht imho nichts gegen einen mnemonischen schlüssel. oder?

[Hansa]

@Daniel :

Zitat:

Zitat von MaBuSE

c2755174-b4f7-4662-85b2-8579c851d48b

Das wurde in Zitat Funktion nicht aufgeführt. Nur zur Info

Zum Thema :

Zitat:

Zitat von MaBuSE

c2755174-b4f7-4662-85b2-8579c851d48b

Der Thread gibt doch was her. Ist tatsächlich einer auf die Idee gekommen, so einen string-PK zu benutzen ? :shock: Wer war das ? :twisted: Sind die Programme uralt von Lochkarten, oder was ?

[Jasocul]

@MaBuSE:
Es sind Integer-IDs.

An GUID hatte ich bisher nicht gedacht. Da müsste man dann allerdings abwägen, ob man den Performance-Verlust zu Gunsten der Funktionalität (weltweiter Abgleich, Offline-Erfassung), akzeptieren kann.

[DP-Maintenance]

Dieses Thema wurde von "r_kerber" von "Klatsch und Tratsch" nach "Datenbanken" verschoben.
Ich denke, das ist kein Klatsch mehr sondern eine Diskussion zu DB-Design. Deswegen verschiebe ich das mal zu Datenbanken.

[Sharky]

Zitat:

Zitat von Hansa

... auf die Idee gekommen, so einen string-PK zu benutzen ? ....

Wie so ist das den ein string-pk? Wie schon erwähnt handelt es sich doch um eine GUID.

[Jasocul]

Ich denke, wenn man die einzelnen Blöcke nicht in Dezimalzahlen umrechnen will, muss man es als String speichern.

[Hansa]

Das ist ja alles schön und gut. Was ich nur nicht verstehe, das ist, wie man so eine "sprechende Nummer" zum PK machen kann. Bzw. sogar zum einzigen Key. Was hindert einen denn dran, zuerst einmal eine ID als PK zu vergeben und dann noch ein Feld mit der komischen Nr. Das ist doch genau das, mit was Mabuse schon kämpfen mußte. Wenn ich einen Artikel habe und 100 Kunden haben dafür Preise hinterlegt. Dann ist es doch IMHO Leichtsinn, die Artikel-Nr. in der DB zu speichern, also als PK. Die ID dient doch gerade zum Entkoppeln von abhängigen Tabellen.

P.S.: Ah ja, verschoben. Und ich weiß, wie es hier hin gelangt ist. War in dem Klatsch und Tratsch-Thread und hatte "neues Thema" angeklickt. 8)

[Sharky]

Zitat:

Zitat von Jasocul

Ich denke, wenn man die einzelnen Blöcke nicht in Dezimalzahlen umrechnen will, muss man es als String speichern.

Dies ist ja nur die Darstellung einer GUID. Diese ist eigentlich nur eine 128 Bit Zahl.

[Jasocul]

Zitat:

Zitat von Sharky

Zitat:

Zitat von Jasocul

Ich denke, wenn man die einzelnen Blöcke nicht in Dezimalzahlen umrechnen will, muss man es als String speichern.

Dies ist ja nur die Darstellung einer GUID. Diese ist eigentlich nur eine 128 Bit Zahl.

Stimmt auffallend. :oops: :wall:
Aber wenn der DB-Designer das nicht weiß, dann nimmt er Strings. :mrgreen:
Ich habe schon Schlimmeres erlebt. :roll:

[Sharky]

Zitat:

Zitat von Jasocul

... dann nimmt er Strings....

Das Problem ist das die DBSM (die ich kenne) keinen GUID-Typ im eigentlichen Sinne kennen.
MS-SQL z.B. kennt zwar den Feldtyp uniqueidentifier. Dieser wird aber intern als ein String aus 32 Zeichen behandelt wenn ich es richtig gelesen hab.

BTW: Delphi kennt den VariablenTyp : TGUID

Aber das ist ja eigentlich nicht das Thema des Threads.

Grundsätzlich denke ich das man mit einem Integer als PK am besten fährt. Aber wenn es zum Beispiel wie von MaBuSE angesprochen um die Sync. von verschiedenen Servern/Datenbanksystemen geht hat die GUID oder andre "sprechende" Schlüsseln natürlich seine Vorteile und auch seine Daseinsberechtigung.

Entscheidend ist die Frage: Wie wirkt sich deren Verwendung auf Geschwindigkeit der Anwendung aus?
Wenn ich z.B eine weltweite Erfassung von Daten mache. Diese Daten teilweise auf verschiedenen Servern und teilweise in lokalen DBs gespeichert werden und meine Abfrage später keine großen Verknüpfungen benötigen bin ich mit der Verwendung einer GUID sicher besser beraten als die Verwendung von Integer-IDs.

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

[eddy]

Hallo Leute,

ich glaube, mir ist etwas entgangen!!

Was ist ein "sprechender Primärschlüssel" ??

Meine Primärschlüssel heißen alle ID und sind vom Typ AutoInc und damit es keine Probleme mit zermatschten Datenbanken gibt (insbesondere mit Paradox-DB) habe ich immer noch einen <Name>ID vom Typ Integer eingeführt, die die Verbindung mit anderen Datenbanken herstellt und <Name> eine Zeichenkette ist, die etwas mit der verwendeten Datenbank zu tun hat (Art = Artikel, Auf = Auftrag usw.)
Die zweite ID bleibt auch dann erhalten, wenn es mal wieder eine Paradox-DB zerlegt hat und sich die Daten nur durch kopieren der einzelnen (unbeschädigten) Datensätzen reparieren ließ, wodurch aber alle ID's vom Typ AutoInc neu erzeugt werden und nicht zwangsläufig mit den originalen übereinstimmten.


mfg
eddy

[Hansa]

Zitat:

Zitat von eddy

...ich glaube, mir ist etwas entgangen!! ...

So ist es. Ein solches Konstrukt ist z.B. eine Art.-Nr. in die man sämtlichen Schwachsin reinpackt. Also PLZ, Warengruppe, Lieferant usw.

[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, die aus mehreren Feldern zusammengesetzt sind. Da wird aber kein einzelnes Feld draus gemacht, sondern einfach ein zusammengesetzter Index gebastelt, der i.d.R. auch noch Unique ist. Aber der PK ist bei mir immer Integer und hat mit dem sprechenden Schlüssel nichst zu tun. Die Relationen zwischen den Tabellen werden auschließlich über den PK definiert, niemals über den sprechenden Schlüssel. Wer es anders macht, sollte erschossen werden. :mrgreen:

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

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

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:

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:

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:

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:

Zitat von Hansa

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.

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:

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:

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 ! :mrgreen: *duck* Ist ja nur Spaß. :lol: 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:

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:

Zitat von Sharky

Zitat:

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:

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:

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:

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:

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ß."