n:m oder m:n, egal? PK der Zwischentabelle?

[Wurliwurm]

Und: Auch ein Kleinwagen will und kann auf der Autobahn fahren, und zwar nicht nur auf der rechten Spur

Wie wichtig ist dafür der Spoiler?

[ebs17]

Da ein Kleinwagen leichter als eine Reiselimousine ist, ist der Effekt des Spoilers bei höheren Geschwindigkeiten wesentlicher, um Bodenhaftung zu halten.

Access ist natürlich kein Ersatz für eine große Datenbank (wer behauptet so etwas?). Es bietet aber trotzdem einiges, was man auch nutzen kann (und daher kennen sollte, statt sich abschätzig zu äußern).

Nebenbei: In drei und mehr Ebenen verschachtelte Subselects sind nicht extrem tief, wenn man sich vor Augen hält, dass nach Spezifikation für Acc2000/Jet 4 50 Ebenen möglich sind. Da kratzt man allenfalls an der Oberfläche und ist weit davon entfernt, vorhandene Möglichkeiten auszureizen.

Im Ernst: Mit Abfragen (SQL) kann man etwas mehr bewerkstelligen, als Daten, die man durch Datenmodellierung und Normalisierung getrennt hat, wieder aneinander zu hängen und dann etwas zu filtern und sortieren.

MfGA
ebs

[Wurliwurm]

Da ein Kleinwagen leichter als eine Reiselimousine ist, ist der Effekt des Spoilers bei höheren Geschwindigkeiten wesentlicher, um Bodenhaftung zu halten.

Was ich mit dem Vergleich (der wie jeder andere Vergleich hinkt) meinte: Ein Kleinwagen wird nicht zum Sportwagen, trotz allem Tuning wie Spoiler o.ä. . Der Unterschied ist unter der Motorhaube. Ich hoffe, das empfindest Du nicht als hochnäsig, wenn ich nochmals betone, daß es bei typischen Access-Anwendungen relativ unkritisch ist, ob das Ergebnis einer "extensiven Abfrage" nach 2 oder 20 Sekunden vorliegt. Wichtiger ist ein übersichtliches Datenmodell, wo man zur Not auch mal händisch eingreifen kann.

50 Ebenen für Subselects sind natürlich ebenso unrealistisch wie die Grenze von 256 Tabellen pro File und 256 Spalten pro Tabelle. Solche Datenbank-Dimensionen gibt es, aber da wird man Access nicht verwenden.

Im Ernst: Mit Abfragen (SQL) kann man etwas mehr bewerkstelligen, als Daten, die man durch Datenmodellierung und Normalisierung getrennt hat, wieder aneinander zu hängen und dann etwas zu filtern und sortieren.

Latürnich. Es kommen Aggregatfunktionen und arithmetische Ausdrücke hinzu. Aber das hat mit dem Primärschlüssel einer Tabelle nichts zu tun.

Ich habe über Dein Argument nachgedacht, daß es bei Subselects ohne einen Einfeld-Index kaum möglich ist, die Ergebnisse einer inneren Abfrage mit "IN" in der äußeren Abfrage zu verwenden(1). Es stimmt.

Meine Idee dazu weiter oben hast Du aber nicht kommentiert:

Es würde dann aber genauso gehen, mit einem
Nichtschlüsselfeld, welches automatisch inkrementiert wird und welches eindeutig
indexiert ist.

Warum kann man, wenn man "extensive Abfragen" machen will, nicht einfach so ein Indexfeld nachrüsten? Das wäre im Sinne der Normalisierung klarer, weil dieses Feld vom Schlüssel (zusammengesetzen Schlüssel!), nur vom Schlüssel und von nichts als dem Schlüssel abhängig wäre. Während der Autowert-Key gegen die 2. Normalform verstößt.


Ich habe auch noch ein bißchen gegoogelt und erlaube mir, folgendes Zitat einzufügen.

http://www.ben-morris.com/identity-surrogate-vs-composite-keys-in-sql-server

...Many people point to a potential performance bonus in using an identity column, but a surrogate key will not improve performance in most cases unless you are selecting records by the surrogate key alone...

...A surrogate key might seem like a tidier solution than a key based on more than one column, but they do not simplify data design – using an identity column over a composite key actually complicates the data design. In order to guarantee data integrity you will have to add a constraint and an index onto the columns that would form the composite key as well as having to create an identity column and primary key...

...There is a distinction between those tables that define entities and those that relate entities.
A table that defines entities is one that describes a single entity within your problem domain, say a person or a product. In this case, a surrogate primary key may well be more appropriate than using the natural key as it is will not be vulnerable to any changes in the characteristics of the entities over time.

However, if you want to relate people and products in a table then this is a different story. The natural key in this case would be a combination of the people and product primary keys. Adding an extra surrogate key would only serve to complicate the design and undermine data integrity without bringing any benefits in terms of performance or maintenance...

Schöner Artikel. Der bringt alles auf den Punkt, was ich gemeint habe.

(1) Damit meine ich nicht nur Zwei-Ebenen-Subqueries.

[ebs17]

Nichtschlüsselfeld, welches automatisch inkrementiert wird und welches eindeutig indexiert ist

Das wäre natürlich auch in etlichen Fällen verwendbar. In einer Verknüpfungstabelle muss aber die Kombination der Fremdschlüssel nicht zwingend eindeutig sein, sie wäre dann als Primärschlüssel ungeeignet. Auf diesen Hinweis bist Du nicht eingegangen, wie auch auf einige weitere.

Und ich wiederhole: Performance ist immer ein Thema.
Was in diesem Zusammenhang als kritisch zu sehen ist (Frust durch Warten, (Selbst-)Mordgedanken) lasse ich uninterpretiert. Erwartungshaltung und Akzeptanz können höchst unterschiedlich ausgeprägt sein.

Eine etwas längere Abfragedefinition oder aber ein längerer Code haben nun aber auch keine direkte Abhängigkeit zur Laufzeit der Abarbeitung.

MfGA
ebs

[Wurliwurm]

Was in diesem Zusammenhang als kritisch zu sehen ist (Frust durch Warten, (Selbst-)Mordgedanken) lasse ich uninterpretiert.

(Selbst-)Mordgedanken wegen länger laufenden Abfragen sind eher ein Fall für den Psychologen. "Kritisch" meine ich rein objektiv. Eine
Abfrage für die Geschäftsführersitzung bei Amazon muß rechtzeitig fertig sein, eine Abfrage nach einer Zugverbindung muß schnell kommen. Ich hatte weiter ja oben ja schon angedeutet, daß es dafür zig Möglichkeiten gibt wie Hauptspeicherpuffer, Materialized Views, Data Warehouses etc.pp., wo die Daten auch denormalisiert und aggregiert vorgehalten werden. In Bezug auf die Eingangsfrage reduziert sich hier die Fragestellung auf: Wieviel bringt ein extra Autowert-PK in einer m:n Relation für die Performance?

Das wäre natürlich auch in etlichen Fällen verwendbar.

In welchen Fällen wäre es nicht verwendbar und im Gegensatz dazu ein einzelner Autowert-PK die Lösung?

In einer Verknüpfungstabelle muss aber die Kombination der Fremdschlüssel nicht zwingend eindeutig sein, sie wäre dann als Primärschlüssel
ungeeignet.

Diese Frage hatte ich weiter oben schon beantwortet. Wenn der Faktor Zeit zum Beispiel dazu kommt, dann muß der
Schlüssel erweitert werden. Das Problem liegt in der Sache und wird nicht dadurch geheilt, indem man einen zusätzlichen
AutoID-Schlüssel hinzugefügt. Durch das Setzen eines zusammengesetzten Primärschlüssel wird ein eindeutiger Index erzeugt. Und durch das
Ergänzen mit einem Sekundärindex könnten auch die Unterabfragen genauso formuliert werden und wären genauso schnell.

Auf diesen Hinweis bist Du nicht eingegangen, wie auch auf einige weitere.

Bitte die "einigen weiteren" Hinweise benennen.

Eine etwas längere Abfragedefinition oder aber ein längerer Code haben nun aber auch keine direkte Abhängigkeit zur Laufzeit der Abarbeitung.

Natürlich hängt das von vielen Faktoren ab, aber hier reduziert sich das auf die Frage, wie Indexe beitragen können zu Performance. Außer in
den Fällen, die Du genannt hast (korrelierte Unterabfragen mit "SELECT IN" aus einer nichtaggregierten Unterabfrage) kann der Index
Autowert-PK nicht benutzt werden.

[oma]

Hallo Kollegen,

ich habe euren Diskurs verfolgt, mir fehlt aber zu einigen, sicher spaß gemeinten Vergleichen der sinnhafte praktische Zugang .

eigentlich ist doch schon alles gesagt:

in #1 Klaus:  

...ich würde als PK einen Autwert verwenden. Ein einzelner PK ist im weiteren Verlauf der Entwicklung der DB leichter zu handhaben.

hierbei ist "weiteren Verlauf der Entwicklung der DB" zu beachten, denn wie oft kommt es vor, dass zu 2 Schlüsselfeldern noch weitere Felder hinzukommen,

siehe 4# ebs

...Wenn in der Zwischentabelle die Verknüpfungen um weitere Informationen wie Gültigkeitsbegrenzungen u.ä. ergänzt werden, entstehen durchaus eigene Informationseinheiten.
Wenn man etwas extensiver Abfragen schreibt, ist es durchaus hilfreich, wenn man ein Feld als Schlüssel zum Verknüpfen verwenden kann als einen Mehrfelderindex

somit gibt es (mindestens) 2 Gründe, in einer m:n Tabelle einen zusätzlichen PK-Wert einzuführen.

sorry, aber alles weitere ist ein ziemlich akademisches Geplänkel, denn man braucht doch diese Gründe nicht zu hinterfragen; die praktische Frage an Wurliwurm ist doch: was schadet es denn

Gruß Oma

[Wurliwurm]

eigentlich ist doch schon alles gesagt:

Hast Du nur die eine Hälfte gelesen oder nur die eine Hälfte verstanden? Es fehlt:

Mein Argument war, daß es dem Lernenden und der Verständlichkeit von Datenmodellen
dient, wenn man Kardinalitäten von m:n analog zum Entity-Relationship-Diagramm auch in
der Datenbank so modelliert.

Adding an extra surrogate key would only serve to complicate the design and undermine data integrity without bringing any benefits in terms of performance or maintenance...

hierbei ist "weiteren Verlauf der Entwicklung der DB" zu beachten, denn wie oft kommt es vor, dass zu 2 Schlüsselfeldern noch weitere Felder hinzukommen,

Dann ändert sich die Kardinalität der Beziehung so grundlegend, daß der Schlüssel nicht mehr stimmt und geändert werden muß.

Wenn man etwas extensiver Abfragen schreibt, ist es durchaus hilfreich, wenn man ein Feld als Schlüssel zum Verknüpfen verwenden kann als einen Mehrfelderindex

Ist mit einem Sekundärschlüssel sauberer lösbar, siehe weiter oben.

die praktische Frage an Wurliwurm ist doch: was schadet es denn

Ist auch schon gesagt: Es verletzt die Normalformen und macht die Struktur weniger überschaubar.

I

[database]

Da gab es doch ganz am Anfang eine klar und deutlich definierte Frage:

Was ist der Primärschlüssel der Zwischentabelle? Muss ich ein AutoID einfügen oder geht auch folgendes: Zitat ...

Ein AutoWert-Feld als PK einzuführen ist ein KANN aber nicht unbedingt ein MUSS - die Erklärung des Herstellers in der zitierten Quelle
ist eine Lösung bei der jedoch eine Kombination der beiden Fremdschlüssel nur einmalig vorkommen darf.

Aber wie mach ich das in Access, also zwei FK als PK zu definieren?

Markiere im Tabellenentwurf beide Fremdschlüsselfelder und klicke auf das Schlüsselsymbol um diese beiden Felder zu einem PK zu machen.

...wäre es denn nicht viel einfacher einem Fragesteller eine klare und deutlich verständliche Antwort zu geben anstatt ellenlange Diskussionen um des Kaisers Bart zu führen?

[ebs17]

...wäre es denn nicht viel einfacher einem Fragesteller eine klare und deutlich verständliche Antwort zu geben

Das ist aber längst erfolgt: Per Link, wo sogar Bilder anzuschauen sind.

MfGA
ebs

[database]

Hallo ebs

...stimmt, ist mir wegen des Farbfehlers auf meinem alten Monitor leider nicht gleich beim ersten Lesedurchgang aufgefallen. 
Meine freundlich gemeinte Kritik war jedoch nicht in deine Richtung ausgelegt. 

[oma]

Hallo,

@wurliwurm: 

Hast Du nur die eine Hälfte gelesen oder nur die eine Hälfte verstanden?

Ich finde solche Bemerkungen unfreundlich.
Ich habe alles gelesen und nicht alles verstanden, was auch teilweise an Formulierungen lag.
Wir hatten uns aber schon einmal verständigt, das dein Wissen über das der übrigen Forumsteilnehmer liegt und du insofern auch Geduld mit Unwissenden aufbringen musst

Ansonsten teile ich die Auffassung das mit #1, #4 und #7 für Johnny sachgerechte Antworten gegegeben sind.

Gruß Oma

[Wurliwurm]

Ich finde solche Bemerkungen unfreundlich.

Entschuldigung! Daß ich hier manchmal rechthaberisch rüberkomme, weiß ich und mag das auch nicht.

Wenn ich sonst ruhig bin und nicht rechthaberisch rüberkomme, dann nimm einfach an:
-die Antworten der anderen Forumsteilnehmer sind richtig oder
-ich weiß es auch nicht (besser)

Im dem Fall, wo ich überzeugt bin, Recht zu haben und meine, das auch bewiesen zu haben, ärgert mich die Formulierungen "akademisches Geplänkel".

Ich kann nur versuchen, das mit einem Vergleich zu verdeutlichen: Der Lehrer in der Schule bringt Deinem Kind bei, jeder arithmetische Ausdruck müsse grundsätzlich und immer mit 1 malgenommen werden. Warum: Er mache das schon immer so und habe immer richtige Ergebnisse. Du behauptest, daß das nicht nötig sei und versuchst ihm das zu beweisen. Als Antwort bekommst Du, daß das akademisches Geplänkel ist, ein Streit um "Kaiser´s Bart" und fragt Dich, was Dich denn daran stört, alle Ergebnisse sind doch richtig ...

Die Anleitung zum Anlegen des zusammengesetzten Schlüssels habe ich nicht gelesen, weil ich davon ausgehe, daß sie richtig ist. Im übrigen bin ich der Meinung, daß die von dir genannten Antworten von mir sachgerecht widerlegt sind.

Der Autowert-PK bei m:n-Tabellen ist einfach schlechter Stil und ich wenn er wieder mit Zusätzen wie "grundsätzlich", "immer", "auf jeden Fall" empfohlen wird, werde ich das hinterfragen.

[oma]

Hallo Johannes Wurliwurm,

Entschuldigung ist natürlich angenommen-zumal ich auch manchmal im "Streitgespräch" zu unnötigen Sticheleien neige.

Die Bemerkung  "...ellenlange Diskussionen um des Kaisers Bart zu führen?" war wohl auch auf die doch ziemlich langatmige und mit verwegenen Beispielen gespickte Diskussion, die auch den Fragesteller wahrscheinlich nicht mehr interessiert hat (da er sich nicht mehr geäußert hat)

Der Autowert-PK bei m:n-Tabellen ist einfach schlechter Stil und ich wenn er wieder mit Zusätzen wie "grundsätzlich", "immer", "auf jeden Fall" empfohlen wird, werde ich das hinterfragen.

Recht hast du, wenn man das mit grundsätzlich und immer Im Sinne von "immer" und "absolut richtig" behauptet wird.

Ich habe allerdings  ein triviales Beispiel, dass für mich eine Sinnfälligkeit eines Auto-PK in einer m:n - Tabelle ergab:

Ich hatte ( sinngemäß) ein Problem für Projekte und Mitarbeiter, wobei die Mitarbeiter in verschiedenen Projekten arbeiten können. Die Tabelle war damit

tblProjektMitarbeiter: Projekt_ID, Mitarbeiter_ID

Später kam der Wunsch hinzu , den Beginn der Mitarbeit des Mitarbeiters an ein Projekt zu speichern. Somit wurde aus der Tabelle:

tblProjektMitarbeiter: PM_ID, Projekt_ID, Mitarbeiter_ID, DatumBeginn, Bemerkung

Deine Bemerkungen:

Dann ändert sich die Kardinalität der Beziehung so grundlegend, daß der Schlüssel nicht mehr stimmt und geändert werden muß. Es verletzt die Normalformen und macht die Struktur weniger überschaubar.

habe ich überhaupt nicht in Betracht gezogen, da die Normalformen wichtige, aber nicht in jedem Fall immer einzuhaltende Bedingungen sind und von wenig überschaubar kann in diesem Fall auch keine Rede sein.
Der "Zugriff" auf einen bestimmten Datensatz war somit mit einem Schlüssel möglich (natürlich wäre es auch mit 2 Schlüssel gegangen) und die Lösung war einfach und praktikabel (auch wenn du anführst: weit ab von der Theorie)

Gruß Oma

[Wurliwurm]

Später kam der Wunsch hinzu , den Beginn der Mitarbeit des Mitarbeiters an ein Projekt zu speichern. Somit wurde aus der Tabelle:
tblProjektMitarbeiter: PM_ID, Projekt_ID, Mitarbeiter_ID, DatumBeginn, Bemerkung

Hallo Oma,

Der extra ID-Schlüssel wäre in dem Fall überhaupt nicht nötig gewesen! Weil sich an der Relation
überhaupt nichts ändert, es bleibt eine m:n-Beziehung. An dem Schlüssel (PM_ID, Projekt_ID)
könnten neben DatumBeginn und Bemerkung beliebig viele Nichschlüsselattribute hängen wie
Tarif, geleistete Stunden, LeistungsBewertung und so weiter.

Die Kardinalität ändert erst dann, wenn etwa ein Faktor Aufgabe etwa so hinzukommen soll
tblProjektMitarbeiterAufgabe: *Projekt_ID, *Mitarbeiter_ID, *AufgabeID, ... -> Nichtschlüsselattribute
sprich pro Projekt/Mitarbeiter/Aufgabe die Daten genau aufgeschlüsselt werden sollen.

Das wäre dann eher eine neue Tochtertabelle tblProjektMitarbeiterAufgabe, die mit der Tabelle tblProjektMitarbeiter per n:1 verknüpft wäre in

dem Sinne:
FOREIGN KEY(ProjektID, Mitarbeiter_ID) REFERENCES tblProjektMitarbeiter(ProjektID, Mitarbeiter_ID)

So eine weitere Verschachtelungsebene ist m.E. wirklich nötig, wenn die Aufgaben extra erfasst werden müssen. Ein Join müßte natürlich immer über beide Attribute erfolgen. Das finde ich sauber, ich kenne und mache das immer so.

Hatte ich aber eigentlich oben alles schon langatmig ausgeführt ... war aber scheinbar leider nur für mich selbst ;-)
Den ursprünglichen Threadersteller haben wir vergrault, das ist mir schon klar.

Johannes
-----
Im Disput. – Wenn man zugleich einer anderen Meinung widerspricht und dabei seine eigene entwickelt, so verrückt gewöhnlich die fortwährende Rücksicht auf die andere Meinung die natürliche Haltung der eigenen: sie erscheint absichtlicher, schärfer, vielleicht etwas übertrieben.
Nietzsche - Menschliches, Allzumenschliches

[MzKlMu]

Hallo,
wollte mich noch mal kurz einmischen. Auch renomierte Datenbankentwickler verwenden in Ihren Beispielen einen extra Autowert.
Z.B. Allen Browne. Was natürlich nicht zwangsläufig heist, dass es richtig ist.

Microsoft Access Tips for Casual Users

Da solche Links in den Foren sehr verbreitet sind bzw. werden, muss man sich also nicht wundern.
Insofern, fühle ich mich mit meiner Empfehlung einen Autowert zu verwenden in guter Gesellschaft.

Ich möchte auf keinen Fall die Diskussion von vorne beginnen, ich bin fachlich nicht in der Lage das so tiefgründig zu betrachten und zu begründen.
Ich beteilige mich schon sehr lange an verschiedenen Access Foren und habe die Erfahrung gemacht, dass auch User die ganz konsequent auf Normalisierung achten auch einen zusätzlichen Autowert empfehlen. Diese Erfahrung versuche ich weiterzugeben. Dass das nicht immer richtig ist/sein muss ist mir auch klar.

Aber dazu gibt es ja solche Foren, möge jeder sein eigenes Fazit aus solchen Diskussionen ziehen. Wobei man natürlich darauf achten sollte, das richtige Fazit zu ziehen.  

Ich persönlich würde zwischenzeitlich bei einer einfachen n:m Tabelle auf den Autowert verzichten.