nicht angemeldet
Hi,
von den 3 tabellen, die er angegeben hat, handelt es sich um eine n:m beziehung. aber von seinen aussagen her, ist die beziehungstabelle überflüssig. er schrieb, eine company kann zwar mehrere objekte haben, aber umgekehr hat er nichts dazu gesagt.
in aller Regel werden bereits etwas kompliziertere Sachverhalte nicht mehr vollstaendig beschrieben. Die "Luecken" fuellt man dann mit den passenden Defaultwerten. Gelingt das nicht, fragt man nach. Der Initialposter machte auf mich den Eindruck, dass er weiss, was er macht. (PS: beim nochmaligen Durchlesen des Initialbeitrag halte ich jetzt doch "alles" ("1:1", "1:n" ;-) fuer moeglich) Darum ging ich von einer "n:m"-Beziehung aus. Ich behaupte zudem, dass diese kleine Spekulation angemessen war.
also gehe ich erst einmal davon aus, dass ein objekt nicht mehrere companies haben kann. und dann handelt es sich um eine 1:n beziehung. eine n:m ist zwar durch aus denkbar und seine strukturen sind so aufgebaut. aber es ist auf jeden fall schon mal sehr fraglich. aber ohne ihn können wir das sowieso nicht ganz klären. also lassen wir es mal offen und gehen einfach von der m:n beziehung aus.
Gut!
Weil jede in der Relationentabelle gehaltene Relation jeweils auf einen Datensatz der Tabelle 'company' und auf einen der Tabelle 'bestimmte Objekte' zeigt. Du willst mir doch nicht das Wort Zeiger verbieten, oder?
schau ludger. ich weiss nicht warum du die aussage ignorierst, dass es sich bei relationen um tabellen handelt.
Also, ich erklaere Dir das mal. Relationen sind Beziehungen. Moeglicherweise habe ich da einen bestimmten Jargon nicht getroffen und haette von relationships sprechen sollen, aber das ist doch beknackt. Und Deine Arroganz (sicherlich unbewusst, aber vorhanden) jetzt mich und andere auf den von Dir verwendeten Jargon einzuschwoeren ist unangebracht. Denn das, was ich geschrieben habe, ist richtig und wird demzufolge auch allgemein verstanden.
entweder hast du noch eine andere meinung dazu, wobei ich nicht weiss, welchen klärungsbedarf es dabei noch gibt, nachdem ein zitat aus deinem link wortwörtlich besagt, bei relationen handelt es sich um tabellen. oder aber du versuchst zu provozieren. übersetzt bedeutet dein satz folgendes:
"Weil jede in der Tabelletabelle gehaltene Tabelle jeweils auf einen Datensatz der Tabelle 'company' und auf einen der Tabelle 'bestimmte Objekte' zeigt."
macht das sinn ?
Das ist halt bekloppt und spricht ganz offensichtlich gegen den von Dir verwendeten Jargon.
und natürlich werde ich dir kein wort verbieten, nur weiss ich nicht welche bedeutung das wort zeiger in der group by klausel haben soll. dabei handelt es sich um spaltennamen, die dort angegeben werden. was also soll das wort zeiger dort für einen sinn haben ?
Ich habe die beiden Datenfelder, die aus der Relation (dem einzelnen Datensatz) heraus auf die Tabellen 'company' und 'andere Objekte' zeigen, mit den Namen 'Zeiger1' und 'Zeiger2' versehen.
Auch hier bitte ich Dich mit Wertungen zurueckzuhalten. Nein, ich bin nicht bereit von Dir vorgegebenes Vokabular so ohne Weiteres zu uebernehmen.
und um auf die abfrage zurückzukommen und warum zwei spaltenangaben kritisch sind. handelt es sich wirklich um eine n:m beziehung, dann vereinfacht dies die gesuchte abfrage. schließlich befindet sich alles wissenswerte in nur einer tabelle, nämlich der beziehungstabelle (relationship-tabelle).
Wie hoert sich denn 'relationship-tabelle' an? Fehlt es uns da vielleicht an Deutschem Vokabular? BTW - wie wuerdest Du die englischen Woerter 'relation' und 'relationship' ins Deutsche uebersetzen?
dort stehen sowohl die company_id's als auch die object_id's. ich brauche dort also nur über die company_id gruppieren und mit hilfe der HAVING klausel die count(*) = 1 einbinden. jede weitere spalte, die ich in der GROUP BY klausel angebe kann aber die gruppierung verändern und hat somit einfluss auf die count(*) aggregat-funktion.
Ja, es geht eben darum, was man erreichen will.
Gruss,
Ludger