Primary Key immer nötig?

[Eddie]

Hallo allerseits,

es gibt ja logischerweise Tabellen, auf die nicht verwiesen wird (mittels Fremdschlüssel). Eigentlich bräuchte man da also nicht unbedingt einen Primärschlüssel - er wird ja nicht genutzt.

Mein Modellierungstool spuckt mir aber immerhin eine Warnung aus, darum moechte ich das mal hinterfragen. Macht es Sinn, den PK manchmal einzusparen?

Beispiel: die Hilfstabelle, die ich für eine n:m-Relation nehme, enthält eigentlich nur 2 Fremdschlüssel - mehr erscheint mir nicht nötig.

Danke für eure Hilfe,
Eddie

[Tom]

Hello,

Beispiel: die Hilfstabelle, die ich für eine n:m-Relation nehme, enthält eigentlich nur 2 Fremdschlüssel - mehr erscheint mir nicht nötig.

Und die solltest Du dann als Kombinationsschlüssel unique deklarieren, dann sind sie automatisch der PK der Tabelle, ob Du das nun noch extra kennzeichnest oder nicht. Alles andere würde den gültigen Regeln für Datenmodelle widersprechen.

Jede andere Tabelle sollte auch einen PK haben, wie willst Du sonst auf den Datensatz gezielt zugreifen? Könnte ja mal sien, dass Du eine Bearbeitertabelle hast, und zwei Bearbeiter mit dem Namen 'eddi'.

Wie willst Du die unterscheiden?

Du weißt:
Was ist der Unterschied zwischen einer Taube?
Die beiden Beine.
Besonders das linke.
Es ist gleich lang.

Harzliche Grüße vom Berg
http://www.annerschbarrich.de

Tom

[Frank (no reg)]

Hi,

Alles andere würde den gültigen Regeln für Datenmodelle widersprechen.

ich würde das nicht so pauschal und ultimativ in den Raum stellen.

Die Konzepte "Schlüssel" (und natürlich deren Implementierung) können durchaus je nach DBMS variieren.

Dein Beispiel mit der Bearbeitertabelle ist ein Standardanwendungsfall für einen Otto Normalverbraucher unter den (relationalen) Datenbankentwicklern. Unter solchen Voraussetzungen (Standard-dies, Standard-das) lassen sich natürlich auch allgemeine Ratschläge geben.

Aber was ist, wenn mir die Sortierung oder der explizite Zugriff nach Kriterium auf den "eddi"-Datensatz Wurscht ist?

Imho heissen relationale Tabellen ohne primäre Ordnung, also Primary Key: "Heap-Tabelle". Zmd kenne ich diesen Begriff in dem Zusammenhang aus der Praxis. Und ich benutze recht häufig solche Heaptabellen ... !! aber !! eben für spezielle Anwendungsfälle.

Also bitte Vorsicht mit Pauschalisierungen :)

So long,
Frank

[Ilja]

yo,

Die Konzepte "Schlüssel" (und natürlich deren Implementierung) können durchaus je nach DBMS variieren.

das prinzip des eindeutigen schlüssel tritt schon vor der implementierung bei der fachlichen modellierung auf.

Imho heissen relationale Tabellen ohne primäre Ordnung

was ist den bitte eine relationale Tabelle ? so etwas gibt es nicht.

Ilja

[Frank (no reg)]

Hallo,

was ist den bitte eine relationale Tabelle ? so etwas gibt es nicht.

War es jetzt so schwer mal 3cm weiter zu denken und gedanklich "relationale Tabelle" in "Tabelle in einem relationalen DBMS" zu übersetzen?

das prinzip des eindeutigen schlüssel tritt schon vor der implementierung bei der fachlichen modellierung auf.

Das Prinzip muss ich bei mir dann berücksichtigen, wenn ich entschieden habe, dass ich ein relationales Datenbankmodell implementieren will. Vorher ist es schnuppe.

"fachliche Modellierung" ?? So was gibt es nicht.

Ist ein genauso bescheuertes Statement wie dein "so etwas gibt es nicht"?

So long,
Frank

[Ilja]

yo,

was ist den bitte eine relationale Tabelle ? so etwas gibt es nicht.

War es jetzt so schwer mal 3cm weiter zu denken und gedanklich "relationale Tabelle" in "Tabelle in einem relationalen DBMS" zu übersetzen?

wenn es nicht so schwer ist, dann schreib es doch auch, damit alle vom gleichen sprechen. es gibt keine relationalen tabellen, weil eine relation eine tabelle ist.

Ilja

[Frank (no reg)]

... es hätte doppelt so viel Tipparbeit erfordert ;)

Hast du da nicht ein "k" bei (k)eine vergessen, im letzten Teil der Antwort?

Könnten wir eigentlich auch damit aufhören über Formulierungen und Verständnisvoraussetzungen zu debattieren?

So long, Frank

[King^Lully]

Könnten wir eigentlich auch damit aufhören über Formulierungen und Verständnisvoraussetzungen zu debattieren?

LOL - amüsiert ihr Euch gerade hier ein wenig.

Mal am Rande: Eine Relation ist eine Objektbeziehung, ob das jetzt eine Tabelle sein muss, na ja. Und "relationale Tabellen"? Warum nicht, als Abgrenzung zu Excel-Tabellen oder ISAM-Tabellen.   ;)

[Jörg Lorenz]

Und "relationale Tabellen"? Warum nicht, als Abgrenzung zu Excel-Tabellen oder ISAM-Tabellen.   ;)

Anscheinend rechnest Du auch mit dem Taschenrechner und gibst die Ergebnisse in Excel ein. Aber Du bist nicht allein, ich kenne da mehrere solche Typen. Auch solche, die meinen, sie würden sich in Excel auskennen.

Viele Grüße

Jörg

[King^Lully]

Und "relationale Tabellen"? Warum nicht, als Abgrenzung zu Excel-Tabellen oder ISAM-Tabellen.   ;)

Anscheinend rechnest Du auch mit dem Taschenrechner und gibst die Ergebnisse in Excel ein. Aber Du bist nicht allein, ich kenne da mehrere solche Typen. Auch solche, die meinen, sie würden sich in Excel auskennen.

Wieder irgendwas nicht verstanden?

Du störst hier zumindest tendentiell inhaltsreiche Diskussionen mit Deinen Stalking-Attacken.

[Jörg Lorenz]

Und "relationale Tabellen"? Warum nicht, als Abgrenzung zu Excel-Tabellen oder ISAM-Tabellen.   ;)

Anscheinend rechnest Du auch mit dem Taschenrechner und gibst die Ergebnisse in Excel ein. Aber Du bist nicht allein, ich kenne da mehrere solche Typen. Auch solche, die meinen, sie würden sich in Excel auskennen.

Wieder irgendwas nicht verstanden?

Anscheinend hast Du meine Aussage nicht verstanden. Ja, ab und zu sollte man auch mal denken.

Du störst hier zumindest tendentiell inhaltsreiche Diskussionen mit Deinen Stalking-Attacken.

Bilde Dir mal nichts ein.

Viele Grüße

Jörg

[King^Lully]

Und "relationale Tabellen"? Warum nicht, als Abgrenzung zu Excel-Tabellen oder ISAM-Tabellen.   ;)

Anscheinend rechnest Du auch mit dem Taschenrechner und gibst die Ergebnisse in Excel ein. Aber Du bist nicht allein, ich kenne da mehrere solche Typen. Auch solche, die meinen, sie würden sich in Excel auskennen.

Wieder irgendwas nicht verstanden?

Anscheinend hast Du meine Aussage nicht verstanden. Ja, ab und zu sollte man auch mal denken.

Ja, dann erkläre uns doch mal, was Du da wieder zusammengeschrieben hast. Du bist doch nicht blöd, um so weniger verstehe ich nicht warum Du immer wieder Böller-Postings verfasst, die unter den meinigen stehen.

[Frank (no reg)]

Ich kann auch nicht wirklich erkennen, wo der Zusammenhang zwischen Jörgs "Anscheinend rechnest Du auch mit dem Taschenrechner und gibst die Ergebnisse in Excel ein." Antwort und der diskutierten Thematik "was sind oder sind nicht relationale Tabellen" besteht.

Schönes Wochenende
Frank

[Jörg Lorenz]

Ja, dann erkläre uns doch mal, was Du da wieder zusammengeschrieben hast.

Na gut, dann versuche ich es mal.

Und "relationale Tabellen"? Warum nicht, als Abgrenzung zu Excel-Tabellen oder ISAM-Tabellen.   ;)

Darauf bezog sich mein Posting. Ich hatte den Eindruck, dass Du ausdrücken wolltest, dass man in Excel einfach eine Sammlung von Datensätzen erstellen kann - wenn denn überhaupt. Nicht mehr und nicht weniger.

Das stammte von mir und war auch ernst gemeint:

Anscheinend rechnest Du auch mit dem Taschenrechner und gibst die Ergebnisse in Excel ein. Aber Du bist nicht allein, ich kenne da mehrere solche Typen. Auch solche, die meinen, sie würden sich in Excel auskennen.

Ich kenne Leute, die haben Excel gelernt und wissen nicht, dass Excel mehr kann, als dass man die Zellen formatiert. Gut, Excel kann mit Formeln arbeiten, aber was man mit Excel-VBA kann, wissen nur wenige Anwender (zum Glück ;-)). Und da wären wir wieder am Anfang:

Und "relationale Tabellen"? Warum nicht, als Abgrenzung zu Excel-Tabellen oder ISAM-Tabellen.   ;)

Wieso kann man mit Excel kein RDBMS erstellen? Das ist gar nicht mal so schwer …

Du bist doch nicht blöd, um so weniger verstehe ich nicht warum Du immer wieder Böller-Postings verfasst, die unter den meinigen stehen.

Naja, etwas Mitdenken setze ich schon voraus …
Außerdem poste ich nicht nur an Deine Adresse. Einbildung ist …

Viele Grüße

Jörg

[King^Lully]

Du bist doch nicht blöd, um so weniger verstehe ich nicht warum Du immer wieder Böller-Postings verfasst, die unter den meinigen stehen.

Naja, etwas Mitdenken setze ich schon voraus …
Außerdem poste ich nicht nur an Deine Adresse. Einbildung ist …

Dein Problem ist, dass Du einerseits meine gelegentlich schon ein wenig durchgeknallten Beiträge (man will ja unterhalten, das Leben ist doch langweilig genug ;) nicht verstehst, bspw. weil Dir Sachverhalte und Denkweisen entweder nicht zugänglich sind, anderseits aber die feste und sichere Meinung hast, ich wäre dämlich.
Das ginge ja noch, aber Du materialisierst dann Deine Meinung in den bekannten Böllerpostings, was nicht gut ist.

[Jörg Lorenz]

Dein Problem ist, dass Du einerseits meine gelegentlich schon ein wenig durchgeknallten Beiträge (man will ja unterhalten, das Leben ist doch langweilig genug ;) nicht verstehst, bspw. weil Dir Sachverhalte und Denkweisen entweder nicht zugänglich sind, anderseits aber die feste und sichere Meinung hast, ich wäre dämlich.

Nee, dass Du männlich (also herrlich) bist, glaube ich Dir schon.

Das ginge ja noch, aber Du materialisierst dann Deine Meinung in den bekannten Böllerpostings, was nicht gut ist.

Ja, das sagt meine bessere Hälfte auch immer. Wenn ich etwas sage, soll das wohl einschlagen …
Aber deshalb lasse ich mir den Mund nicht verbieten und spiele auch mal etwas mit Andeutungen.

Naja, nun hast Du erstmal Deine Ruhe. Die Koffer sind gepackt, heute habe ich wegen Urlaubslaune sowieso schon nicht mehr gearbeitet und morgen um 07:45 geht der Flug. Endlich mal wieder fliegen (Zufall: ausgerechnet in Deine Richtung) …

Viele Grüße

Jörg

[King^Lully]

Das ginge ja noch, aber Du materialisierst dann Deine Meinung in den bekannten Böllerpostings, was nicht gut ist.

Ja, das sagt meine bessere Hälfte auch immer. Wenn ich etwas sage, soll das wohl einschlagen …
Aber deshalb lasse ich mir den Mund nicht verbieten und spiele auch mal etwas mit Andeutungen.

Das darfst Du ja auch gerne gelegentlich, aber ich zähle mittlerweile vielleicht 100 Aktionen, in denen Du Deine Meinung in Böllerpostings (a.k.a. Stalking-Attacken) materialisierst. Du hast sogar schon die Kunstfigur "Keitlie" kreiert. Da hackt es doch.

Lass Dich mal von Deiner Besseren Hälfte im Urlaub ein wenig aufpäppeln, Du ist zu wenig.

[Jörg Lorenz]

Ja, das sagt meine bessere Hälfte auch immer. Wenn ich etwas sage, soll das wohl einschlagen …
Aber deshalb lasse ich mir den Mund nicht verbieten und spiele auch mal etwas mit Andeutungen.

Das darfst Du ja auch gerne gelegentlich, aber ich zähle mittlerweile vielleicht 100 Aktionen, in denen Du Deine Meinung in Böllerpostings (a.k.a. Stalking-Attacken) materialisierst.

Na, da musst Du wohl nochmal 'ne Abfrage starten. 100 waren es garantiert nicht - ab und zu muss ich auch mal arbeiten. Außerdem brauchst Du Dich nicht verfolgt zu fühlen. Meine aktive Forenzeit ist seit sechs Jahren vorbei. Seitdem schreibe ich mal hier und mal da, gerade so, wie es mir gefällt. Ich sehe nicht alles so verbissen, im Gegenteil.

Du hast sogar schon die Kunstfigur "Keitlie" kreiert. Da hackt es doch.

Jetzt musste ich doch direkt mal suchen - ja, "Keitlie" ist nicht übel.

Lass Dich mal von Deiner Besseren Hälfte im Urlaub ein wenig aufpäppeln, Du ist zu wenig.

Den zweiten Teilsatz verstehe ich nicht so richtig …
Aber nachdem ich nun unsere Sitzplätze für den Flug angeklickt habe (als Spotter natürlich etwas hinter den Tragflächen), mache ich nun Feierabend.

Gehabe Dich wohl und sei Dir sicher - in den nächsten Tagen werde ich garantiert keine Postings von Dir lesen. ;-)

Viele Grüße

Jörg

[Steel]

Jede andere Tabelle sollte auch einen PK haben, wie willst Du sonst auf den Datensatz gezielt zugreifen? Könnte ja mal sien, dass Du eine Bearbeitertabelle hast, und zwei Bearbeiter mit dem Namen 'eddi'.

Wie willst Du die unterscheiden?

Wenn ich garnicht gezielt auf einen Datensatz zugreifen will, dann brauche ich auch keinen Key. Meinen Eddi gaebe es nur einmal und zwar als ID, die der PK der Usertabelle ist...

[Eddie]

Wenn ich garnicht gezielt auf einen Datensatz zugreifen will, dann brauche ich auch keinen Key. Meinen Eddi gaebe es nur einmal und zwar als ID, die der PK der Usertabelle ist...

So ungefähr wäre das auch bei mir: ich lagere zwei beschreibende Attribut aus einer PK-Tabelle aus, und zwar in zwei neue Tabellen:

Farbe:
   fk_Haupttabellen-ID
   farbe

Punkt:
   fk_Haupttabellen-ID
   x
   y

Der Hintergrund ist, dass ein Objekt in der Haupttabelle entweder einen Punkt repraesentiert, oder eine Fläche (mit Farbe), nie beides gleichzeitig.
Darum brauche imho eigentlich keinen PK!

Eddie

[Ilja]

yo,

So ungefähr wäre das auch bei mir: ich lagere zwei beschreibende Attribut aus einer PK-Tabelle aus, und zwar in zwei neue Tabellen:

und was bilden diese beiden spalten (attribute) zusammen mit dem fremdschlüssel auf die haupttabelle ? richtig einen pk.

Ilja

[Tom]

Hello,

Farbe:
   fk_Haupttabellen-ID
   farbe

Das ist nicht ok so:

Punkt:
   fk_Haupttabellen-ID
   x
   y

x und y bilden zusammen einen Kombinationsschlüssel.
fk_Haupttabellen-ID ist ein Fremdschlüssel, gehörts omit formal nicht an erste Stelle der Tabellenbeschreibung. Wenn man die Konventionen einhält (PK immer an erster Stelle, gleichlautetd oder zumindest ähnlich, wie die tabelle heißt) dann kann man Dokumentationen auch lesen.

Nun könntest Du natürlich behaupten, dass es mehrere xy-Datensätze gibt, weil die Farben schließlich auch gemischt werden können. Dann hättest Du hier tatsächlich keinen Primary Key, aber auch wieder keine (datentechnisch saubere) Zugriffsmöglichkeit auf den Datensatz.

Wie Du Dich auch drehst und wendest.
_Keinen_ abstahierten PK anzulegen rächst sich irgendwann später immer.
Man hat früher gerne darauf verzichtet, weil man jedes Byte Speicherplatz sparen musste.
Im Zeitalter von WinDOS ist die Minimalismus-DV doch aber spätestens vorbei gewesen.
Die vier bis acht Bytes pro Datensatz für einen qualifizierten Schlüssel hat man heute einfach übrig. Ausnahmen gibt es sicher auch hier, z.B. bei Single-Chip-Computern in Uhren, Wanzen, Sensoren, ...

Harzliche Grüße vom Berg
http://www.annerschbarrich.de

Tom

[Tom]

Hello,

Jede andere Tabelle sollte auch einen PK haben, wie willst Du sonst auf den Datensatz gezielt zugreifen? Könnte ja mal sien, dass Du eine Bearbeitertabelle hast, und zwei Bearbeiter mit dem Namen 'eddi'.

Wie willst Du die unterscheiden?

Wenn ich garnicht gezielt auf einen Datensatz zugreifen will, dann brauche ich auch keinen Key. Meinen Eddi gaebe es nur einmal und zwar als ID, die der PK der Usertabelle ist...

Dann hast Du ja schon einen Key. Der ist nur nicht datenunabhängig und damit ungeschickt.
Wenn dann später doch relationen zur Tabelle hergestellt werden sollen, sollte der Primärschlüssel immer datenunabhängig sein. Angenommen, eddi möchte in Zukunft 'Eddi' geschrieben werden, dann müsste der Wert als Schlüssel in allen gekoppelten Tabellen auch geändert werden.

Harzliche Grüße vom Berg
http://www.annerschbarrich.de

Tom

[_roro]

Moin,

es gibt ja logischerweise Tabellen, auf die nicht verwiesen wird (mittels Fremdschlüssel). Eigentlich bräuchte man da also nicht unbedingt einen Primärschlüssel - er wird ja nicht genutzt.

ack.

Mein Modellierungstool spuckt mir aber immerhin eine Warnung aus, darum moechte ich das mal hinterfragen. Macht es Sinn, den PK manchmal einzusparen?

Es könnte manchmal Sinn machen. Ja.

Beispiel: die Hilfstabelle, die ich für eine n:m-Relation nehme, enthält eigentlich nur 2 Fremdschlüssel - mehr erscheint mir nicht nötig.

Frag mal so: Was nützt ein Fremdschlüssel in der Detailtabelle, wenn damit der Datensatz in der Haupttabelle nicht referenziert werden kann, weil es in der Haupttabelle keinen primary key gibt?

Ist doch Käse, oder?

--roro

[Christian Seiler]

Hallo Eddie,

es gibt ja logischerweise Tabellen, auf die nicht verwiesen wird (mittels Fremdschlüssel). Eigentlich bräuchte man da also nicht unbedingt einen Primärschlüssel - er wird ja nicht genutzt.

Du musst zwischen "Attribut" (auch "Spalte", "Feld") und "Schlüssel" unterscheiden. Ein Schlüssel ist nicht auf ein einziges Feld beschränkt. Ein Primärschlüssel dient lediglich dazu, einen Datensatz in einer Tabelle eindeutig (!) zu identifizieren. Der Schlüssel kann über mehrere Attribute oder auch nur ein Attribut angelegt werden; wenn er über mehrere Attribute geht, dann definieren die Attribute in ihrer Gesamtheit den Datensatz, sprich: wenn der Primärschlüssel über zwei Attribute geht, dann kennzeichnen die Wertepaare (1,2), (2,1), (1,1) und (2,2) vier verschiedene Datensätze.

Häufig werden in Tabellen Integer-Spalten (id) angelegt, die dann zum alleinigen Primärschlüssel gemacht werden. Allerdings ist dies auch nicht die einzige Möglichkeit und auch nicht immer die sinnvollste.

Beispiel: die Hilfstabelle, die ich für eine n:m-Relation nehme, enthält eigentlich nur 2 Fremdschlüssel - mehr erscheint mir nicht nötig.

Doch, bei m:n-Relationstabellen sind beide Einzelspalten jeweils Fremdschlüssel, beide Spalten _zusammen_ bilden den Primärschlüssel. Denn bei einer m:n-Verknüpfung ist ja ein einzelner Eintrag in der Tabelle eindeutig. Sprich: Das Wertepaar (4, 6) sollte bloß einmal in der Tabelle stehen, sonst bekommst Du bei JOINs doppelte Datensätze.

Du kannst in genau einem Fall auf Primärschlüssel bei Tabellen verzichten (und dann musst Du es sogar), nämlich genau dann, wenn doppelte Datensätze (d.h. Datensätze, bei denen *ALLE* Attribute der Tabelle den gleichen Wert haben) abgespeichert werden sollen *UND* Du die Datensätze *NICHT* eindeutig identifizieren können musst. Aber mir fällt gerade kein Beispiel ein, wo so etwas mal sinnvoll sein könnte - nicht, dass es sowas nicht geben mag, aber ich hab's noch nie gebraucht.

Viele Grüße,
Christian

[King^Lully]

Du musst zwischen "Attribut" (auch "Spalte", "Feld") und "Schlüssel" unterscheiden.

Ein PK ist ein besonderes Attribut. Er sollte keine Bedeutung haben, sonst kann spätere Datenarbeit unangenehm werden, also bspw. wenn irgendwie umverzeigert werden muss.

Ein Schlüssel ist nicht auf ein einziges Feld beschränkt.

Sollte er aber normalerweise sein.

Ein Primärschlüssel dient lediglich dazu, einen Datensatz in einer Tabelle eindeutig (!) zu identifizieren.

Du hast doch mal das Wort "eineindeutig" eingeführt.   LOL
Das schreckliche kleine Ding ist jetzt doch in meinem aktiven Sprachschatz.
"Lerne" ich jetzt auch noch, dass es uneindeutige Identifikation gibt oder eineindeutige?

Häufig werden in Tabellen Integer-Spalten (id) angelegt, die dann zum alleinigen Primärschlüssel gemacht werden. Allerdings ist dies auch nicht die einzige Möglichkeit und auch nicht immer die sinnvollste.

Es ist die sinnvollste. An welche anderen Möglichkeiten denkst Du?

Doch, bei m:n-Relationstabellen sind beide Einzelspalten jeweils Fremdschlüssel, beide Spalten _zusammen_ bilden den Primärschlüssel.

Nö. Da muss sich erst einmal jemand entscheiden diesen einzurichten. Es spricht nichts gegen einen PK, der nicht zusammengesetzt ist.

Sprich: Das Wertepaar (4, 6) sollte bloß einmal in der Tabelle stehen, sonst bekommst Du bei JOINs doppelte Datensätze.

Grundsätzlich ja, aber es gibt wie ich finde sinnvolle Ausnahmen, bspw. wenn Historisierung im Spiel ist.

Du kannst in genau einem Fall auf Primärschlüssel bei Tabellen verzichten (und dann musst Du es sogar), nämlich genau dann, wenn doppelte Datensätze (d.h. Datensätze, bei denen *ALLE* Attribute der Tabelle den gleichen Wert haben) abgespeichert werden sollen *UND* Du die Datensätze *NICHT* eindeutig identifizieren können musst.

Es mag da in der Tat einige, sagen wir mal rein mathematische Daten geben bei denen diese Aussage zutrifft. Ich rate allerdings immer von diesem Vorgehen, sogar von dsbzgl. Überlegungen dringendst ab. "Datensätze ohne PK?" => Todessünde des Datendesigns

PS: Normalerweise analysiere ich Deine Beiträge nicht, aber das mit "eindeutig identifizieren" hat mich an alte Zeiten erinnert.

[King^Lully]

Macht es Sinn, den PK manchmal einzusparen?

Das "Aussparen" des PKs ist eine der Todsünden des Datendesigns. Vermutlich haben Dir die Jungs schon alles erklärt, ansonsten erläutere ich gerne.

Beispiel: die Hilfstabelle, die ich für eine n:m-Relation nehme, enthält eigentlich nur 2 Fremdschlüssel - mehr erscheint mir nicht nötig.

Das ist in der Tat ein Grenzfall. Ist die "Hilfstabelle" überhaupt eine Tabelle oder nicht eine Beziehung? (Soweit ich weiss verwalten manche RDBMSe "n:m"s selbstständig im Hintergrund. Vertrauen hätte ich aber nicht dazu. ;)

Aus prinzipiellen Gründen bekommen bei mir auch "n:m"s einen PK. Ist vielleicht doch eine "kleine Entität" denke ich mir, kriegt einen Zeitstempel und wird bei Historisierung ja auch mit einem Owner und einem DeleteDate versehen das kleine Ding.

Du immer mit Deinen Fragen zum Datendesign!   ;)

[Eddie]

Hi King^Lully,

Du immer mit Deinen Fragen zum Datendesign!   ;)

Ja, schlimm, ich weiss! Du immer mit deinen hilfreichen Antworten zum Datendesign!   ;)
Also danke soll das heissen!

Ich schreib jetzt aber nochmal was oben rein!

Eddie

[Eddie]

Hallo allerseits,

jetzt wollte ich mich nochmal melden! Hab das hier alles aufmerksam verfolgt, und reichlich gelernt!

Und mittlerweile auch mein komplettes Modell (insg. 27 Tabellen) angepasst: nur noch reine n:m-Tabellen ohne weitere Attribute haben jetzt keinen Extra-PK mehr, sondern einen kombinierten.

Und auch so Dinge wie Unique-Strings, die ich als PK eingerichtet hatte, habe ich jetzt nur noch als unique, und einen zusaetzlichen int-PK reingenommen. Ein Beispiel hierfuer war eine Tabelle, die Infos zu URLs enthält, da war die URL bisher der Primary Key...

In diesem Sinne danke euch allen nochmal! Hat mir sehr geholfen!

Eddie