Abfrage in einer n:M Beziehung?

[oma]

Hallo,

@Albert: sorry, dass wir uns auch noch neben dem Thema austauschen.

@ebs:

Ich sehe es als hilfreich an, wenn man neben dem schnellen Tipp auch eine Ahnung/Kenntnis vermittelt, wie es auch sein könnte oder sollte

.

da hast du uneingeschränkt Recht!

Gruß Oma

[database]

Hallo Albert,

sieh mal da rein:
http://www.donkarl.com?FAQ3.16

Wenn du nun Karl Donaubauers Tipp auf deine Datenbank umlegst, würde die Syntax der Abfrage ganz einfach so lauten:

Code [Auswählen] Erweitern


SELECT P.*
   FROM tblProjekte P
       LEFT JOIN tblKunProj KP
       ON P.Pr_id = KP.Pr_id_f
WHERE KP.Pr_id_f  Is Null


Als Ergebnis erhältst du alle Spalten der Tabelle tblProjekte und als Inhalt jene Datensätze, die in der Tabelle tblKunProj keine Entsprechung haben.
Durch den LEFT JOIN in dieser Abfrage werden zur Ergebnisbildung ALLE Datensätze der Tabelle tblProjekte herangezogen und nur jene angezeigt, bei denen
nach der abfragetechnischen Verknüpfung der Tabellen im Feld tblKunProj.Pr_id_f  NULL enthalten ist.

Du kannst das leicht überprüfen in dem du die Abfrage ein klein wenig abänderst und das Feld tblKunProj.Pr_id_f ins Ergebnis mit einbindest:

Code [Auswählen] Erweitern


SELECT P.*, KP.Pr_id_f
   FROM tblProjekte P
       LEFT JOIN tblKunProj KP
       ON P.Pr_id = KP.Pr_id_f
WHERE KP.Pr_id_f  Is Null


Somit ist die SQL um Einiges kürzer und auch für dich leichter lesbar
PLUS - Vorteil: diese Abfrage kannst du 100te mal ausführen ...  ohne Parameterfrage  
Was allerdings auch mit DEINER Version gelingt - keine Ahnung warum du die Parameterfrage gestellt bekommst.

Aber das dauert halt bei mir doch noch ein wenig länger

Macht nix, wir haben Geduld und ich glaube dass wir hier in diesem Forum bereits einige tausendmal gezeigt haben,
dass wir Fragen so beantworten können, dass
erstens die Antwort stimmt,
zweitens das Ergebnis richtig war und
drittens dem Fragesteller nicht nur ein Ergebnis vor die Nase gesetzt und kurzfristig aus der Patsche geholfen wurde
sondern auch die benötigte Erkärung mitgeliefert wurde und zwar SO, dass der FS wusste worum's geht - nachhaltig

@ebs:

Beide Fremdschlüssel dürften gemeinsam einen zusammengesetzten eindeutigen Schlüssel ergeben

Die beiden Fremdschlüssel bilden einen zusammengesetzten PK - richtig erkannt

(der notfalls auch als PK genutzt werden könnte, ein einfacher zusätzlicher Autowert wäre aber praktikabler).

Nix Notfall und nix praktikabler, da durch obige einfache Konstellation gewährleistet ist, dass keines der FK-Felder leer bleibt,
was in der praktikablen Version wiederum nur durch einen zusätzlich zu erzeugenden Index erreichbar gewesen wäre.

[ebs17]

Die beiden Fremdschlüssel bilden einen zusammengesetzten PK - richtig erkannt
Nix Notfall und nix praktikabler ...

Dieser absoluten Verkündigung (so klingt es zumindest) möchte ich dann auch widersprechen:
Für die Fremdschlüsselkombination ist ein zusammengesetzter eindeutiger Index sinnvoll bis notwendig, Primärschlüssel muss er jedoch nicht sein. Dort schätze ich ein normales Autowertfeld bedeutend mehr, der zusätzliche Index belastet innerhalb der 32 möglichen Indices nicht wirklich.

Der Einfeld-PK ist sehr praktikabel. Wenn man Tabellen und (Unter)Abfragen zu richtigen Abfragen verknüpft, und das funktional und nicht nur durch Zusammenklicken und gesteuert über Beziehungen, ist es nicht unerheblich, ob ich da jedes Mal einen Mehrfelderindex verwenden muss oder ob ich einen Einfeld-Schlüssel verwenden kann. Das betrifft zum einen den Umfang für die Gesamtabfrage an sich, zum anderen schließt ein Mehrfelder-PK eine Konstruktion wie "WHERE Feld IN (SELECT ...)" aus, wodurch dann in Umgehung gleich wieder zwei, drei zusätzliche Ebenen in der Verschachtelungstiefe innerhalb der Abfrage entstehen.

da durch obige einfache Konstellation gewährleistet ist, dass keines der FK-Felder leer bleibt

Sauberes Tabellenfüllen ist wichtig und Basis für alles folgende. Im Mittelpunkt steht aber für mich Datenverarbeitung, nicht die Datenerfassung.

Daher bekräftige ich meine Aussage, dass ein Mehrfelder-PK primär ein Notfall ist, und bin gespannt auf Gegenargumente.

MfGA
ebs

[oma]

Hallo,

Daher bekräftige ich meine Aussage, dass ein Mehrfelder-PK primär ein Notfall ist, und bin gespannt auf Gegenargumente.

wir entfernen uns aber ziemlich vom Thema.

Zur obigen  Aussage hatte ich hier im Forum schon einmal einen ziemlichen Streit.  Ich mache grundsätzlich zu jeder Tabelle immer ein ID als PK  mit Felddatentyp Autowert;  für mögliche Datenkonsistenzprüfung anderer Felder lege ich dann evt. einen zusammengesetzten Index an. Ein Mehrfelder-PK  habe ich noch nie benötigt; als Notfall würde ich das aber auch nicht bezeichnen, da immerhin möglich.

Sauberes Tabellenfüllen ist wichtig und Basis für alles folgende. Im Mittelpunkt steht aber für mich Datenverarbeitung, nicht die Datenerfassung.

naja, ich habe Anwendungen zu betreuen, in der täglich 10-25 User heftig Daten eingeben. Da ist Datenerfassung schon wichtig und die Datenverarbeitung (Auswertungen)  ist relativ zeitunkritisch.

Es kommt eben immer auf die Anforderungen und spezifischen Bedingungen an.

Gruß Oma

[ebs17]

wir entfernen uns aber ziemlich vom Thema.

Das eigentliche Thema erscheint mir geklärt, die Parameternachfrage ist mit den gezeigten Abfragen nicht zu erklären. Und ich denke, Albert hat gegen die unbeabsichtigte Horizonterweiterung über die Problemklärung an sich hinaus nicht wirklich etwas einzuwenden. Sichtbar lernt er gerne dazu.

Nix und Basta provozieren aber gerade die Rückfrage nach der versprochenen benötigten Erklärung.

die Datenverarbeitung (Auswertungen)  ist relativ zeitunkritisch

Nun, Theorie und Umsetzung von Datenmodellierung und Normalisierung (= gesammelten Erfahrungen) dienen in hohem Maße dazu, dem Rennwagen SQL als Datenbanksprache Nummer 1 die notwendige Rennstrecke bereit zu stellen. SQL ist eindeutig Verarbeitung von Daten.
Zum puren Eingeben und Sammeln von Daten wären auch Excel-like-Strukturen oder sogar Textdateien geeignet. Möglich sind sie auf jeden Fall, verwendet werden sie durchaus auch. Ob sie erste Wahl sind (das meinte ich präziser mit Nichtnotfall), mag jeder für sich und entsprechend seinen Anforderungen  beurteilen.

MfGA
ebs

[silentwolf]

Hallo an alle
Ja ich habe mal überhaupt nix dagegen wenn Ihr diskutiert und wenn es etwas ausscheifend ist!
Lern ja auch mit und das ist sicher nicht schlecht
Leider wieder etwas wenig Zeit aber für ein kurzes Dankeschön reicht es auf alle male!

Lg Albert

[database]

Hi,

und bin gespannt auf Gegenargumente

KEINE

Ich bin in keiner Weise daran interessiert irgendwelche Grundsatzdiskussionen zu führen, die sowieso niemanden was helfen.
Diese Art von Argumentationen kenn ich zur Genüge

EOF