MySQL: Datensatz mit genau einer Relation

[[e-mail]]

Folgende Situation:

Es gibt eine Tabelle company (company_id) und eine Tabelle object
(object_id)
Eine company kann mehrere Objekte haben. Die Relationen werden in der Tabelle rel_company_object gespeichert.

Nun will ich folgende Datensätze raussuchen:

Suche alle Datensätze aus Tabelle company, die mit einem bestimmten Objekt verknüpft sind und für die es in der Tabelle object genau eine Relation gibt.

Mit anderen Worten:
alle companies, die mit einem bestimmten Objekt verknüpft sind, aber die companies ausgenommen, die zusätzlich auch noch mit anderen Objekten verknüpft sind.

Wie würde eine solche ABfrage ungefähr aussehn?

[Ludger]

Hi,

Wie würde eine solche ABfrage ungefähr aussehn?

select
 count(*),
 Zeiger1,
 Zeiger2
from
 Relationenttabelle
GROUP BY
 Zeiger1,
 Zeiger2
HAVING
 (count(*) = 1)

So kriegst Du die Relationen, die es nur einmal gibt. Den REst machst Du mit Sub-SELECTs.

Gruss,
Ludger

[Ilja]

yo,

Eine company kann mehrere Objekte haben. Die Relationen werden in der Tabelle rel_company_object gespeichert.

eine relation ist ein anderes wort für tabelle und nicht für beziehungen. das wird leider oft verwechselt. beziehungen sind relationships.

Wie würde eine solche ABfrage ungefähr aussehn?

nun ungefähr ist im zusammenhang mit abfragen ein wenig widersprüchlich, da kleine abweichungen größe wirkungen haben können. aber ich kann ja mal in worten antworten. du brauchst einen inner join, wobei die objekte tabelle noch eine bestimmte objekt_id Bedignung hat und ein group by über die company_id mit eine having einschränkung über die anzahl der datensätze count(*) = 1

Ilja

[Ludger]

Hi,

eine relation ist ein anderes wort für tabelle und nicht für beziehungen. das wird leider oft verwechselt. beziehungen sind relationships.

fragen wir mal

_MISTER_CHECK_

http://app.mr-check.de/a31db05310e9661a316a6a618b708208/v2.0/Mrcheck.php?CID=tanto1&SB=Relation

Gruss,
Ludger

[Ilja]

yo,

fragen wir mal

_MISTER_CHECK_

http://app.mr-check.de/a31db05310e9661a316a6a618b708208/v2.0/Mrcheck.php?CID=tanto1&SB=Relation

ich sehe dort nur, dass er mit anderen worten das schreibt, was ich gesagt habe, was relationen in bezug auf datenbanken betrifft. tupel sind nun mal tabellen.

Ilja

[Ludger]

Hi,

fragen wir mal

_MISTER_CHECK_

http://app.mr-check.de/a31db05310e9661a316a6a618b708208/v2.0/Mrcheck.php?CID=tanto1&SB=Relation

ich sehe dort nur, dass er mit anderen worten das schreibt, was ich gesagt habe, was relationen in bezug auf datenbanken betrifft. tupel sind nun mal tabellen.

ich lese da was anderes.

Auch interessant, dass Du

eine relation ist ein anderes wort für tabelle und nicht für beziehungen.

aus Deinem Beitrag herausschnippelst.

Gruss,
Ludger

[Ilja]

yo,

ich lese da was anderes.

dann klick doch mal auf der seite auf den link relational und schau dir an, was dort steht.

Ilja

[Struppi]

Auch interessant, dass Du

eine relation ist ein anderes wort für tabelle und nicht für beziehungen.

aus Deinem Beitrag herausschnippelst.

Hmm, ich lese dort auch:
Sie fassen die Daten bestimmter Zusammenhänge zu Gruppen zusammen, den Diskursbereichen. Diese Gruppen sind im Prinzip wieder Tabellen.

Klingt für mich eindeutig.

Struppi.

[Ludger]

Hi,

Auch interessant, dass Du

eine relation ist ein anderes wort für tabelle und nicht für beziehungen.

aus Deinem Beitrag herausschnippelst.

Hmm, ich lese dort auch:
Sie fassen die Daten bestimmter Zusammenhänge zu Gruppen zusammen, den Diskursbereichen. Diese Gruppen sind im Prinzip wieder Tabellen.

Klingt für mich eindeutig.

richtig, Gruppen von Relationen sind Tabellen, eben Relationentabellen. Eine Relation ist natuerlich keine Tabelle.

Gruss,
Ludger

[Ilja]

yo,

richtig, Gruppen von Relationen sind Tabellen, eben Relationentabellen. Eine Relation ist natuerlich keine Tabelle.

warum schaust du dir nicht erst mal deine query genauer an, ob eine zweite spalte in der group by klausel nicht etwas problematisch ist, bevor du dich mit solch theoretischen dingen auseinander setzt.

Ilja

[Ludger]

Hi,

warum schaust du dir nicht erst mal deine query genauer an, ob eine zweite spalte in der group by klausel nicht etwas problematisch ist, bevor du dich mit solch theoretischen dingen auseinander setzt.

was ist an dem GROUP BY Zeiger1, Zeiger2 'etwas problematisch'?

Gruss,
Ludger

[Ilja]

yo,

was ist an dem GROUP BY Zeiger1, Zeiger2 'etwas problematisch'?

es verändert die gruppen zusammensetzung und hat somit einfluss auf die count(*) aggregat-funktion.

Ilja

[Ludger]

Hi,

was ist an dem GROUP BY Zeiger1, Zeiger2 'etwas problematisch'?

es verändert die gruppen zusammensetzung und hat somit einfluss auf die count(*) aggregat-funktion.

Du solltest versuchen Dich klarer auszudruecken. Ich wuesste nicht, was der Anforderungslage

"Suche alle Datensätze aus Tabelle company, die mit einem bestimmten Objekt verknüpft sind und für die es in der Tabelle object genau eine Relation gibt."

bei meiner Antwort nicht entsprochen hat.

Wir haben zwei Tabellen, eine Relationentabelle, die eine many to many Beziehung abbildet, also dementsprechend zwei Zeiger.

Gruss,
Ludger

[Ilja]

yo,

Du solltest versuchen Dich klarer auszudruecken.

meine aussage ist und war klar. sie ist aber nur ein teil, man muss sie auch verstehen wollen. insofern solltest du vielleicht weniger kritik an anderen üben, sondern erst ein mal ein wenig über das gesagte nachdenken, bevor du wieder wie ein feuerwerk erscheinst, um dann wieder in der dunkelheit zu verschwinden, wenn deine aussagen doch nicht so klangvoll am himmel erscheinen, so wie du es bei den relationen getan hast.

"Suche alle Datensätze aus Tabelle company, die mit einem bestimmten Objekt verknüpft sind und für die es in der Tabelle object genau eine Relation gibt."

wichtig ist hier, dass es genau einen datensatz pro company gibt. dabei ist zu beachten, welche gruppen nun letztzlich über das group by gebildet werden. die bildung der gruppen wird die anzahl der datensätze beeinflussen.

Wir haben zwei Tabellen, eine Relationentabelle, die eine many to many Beziehung abbildet, also dementsprechend zwei Zeiger.

obwohl wir eigentlich geklärt haben, was eine relation ist und es insofern keine relationstabelle geben kann, irrst du dich mit deiner aussage. es ist eine 1:n beziehung. und selbst wenn es sich um eine n:m bezihung handeln sollte, heisst das noch nicht, dass es zwingend zwei spalten in der group by klausel geben muss. was der quatsch mit den zeigern soll, weiss ich auch nicht.

Ilja

[Ludger]

Hi,

Du solltest Dich um Sachlichkeit bemuehen. Zudem vielleicht auch die Hochnaesigkeit ein wenig zurueckfahren.

"Suche alle Datensätze aus Tabelle company, die mit einem bestimmten Objekt verknüpft sind und für die es in der Tabelle object genau eine Relation gibt."

wichtig ist hier, dass es genau einen datensatz pro company gibt. dabei ist zu beachten, welche gruppen nun letztzlich über das group by gebildet werden. die bildung der gruppen wird die anzahl der datensätze beeinflussen.

Wieso? Wir haben die Tabellen 'company', 'bestimmte Objekte' und die Tabelle, die die Relationen haelt. Das ist dann eine "n:m"-Beziehung.

Wir haben zwei Tabellen, eine Relationentabelle, die eine many to many Beziehung abbildet, also dementsprechend zwei Zeiger.

obwohl wir eigentlich geklärt haben, was eine relation ist und es insofern keine relationstabelle geben kann, irrst du dich mit deiner aussage. es ist eine 1:n beziehung. und selbst wenn es sich um eine n:m bezihung handeln sollte, heisst das noch nicht, dass es zwingend zwei spalten in der group by klausel geben muss. was der quatsch mit den zeigern soll, weiss ich auch nicht.

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?

Gruss,
Ludger

[Ilja]

yo (bemüht sachlich zu bleiben),

Wieso? Wir haben die Tabellen 'company', 'bestimmte Objekte' und die Tabelle, die die Relationen haelt. Das ist dann eine "n:m"-Beziehung.

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

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

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 ?

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

Ilja

[Ludger]

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

[Ilja]

yo,

vielleicht solltest du dir noch mal vor augen führen, dass du mich mit deinem link überzeugen wolltest, was relationen sind. nicht ich will dir etwas vorschreiben. ich sage nur was relationen im sinne von datenbanken sind. dass viele darunter etwas falsche verstehen ist mir klar. gerade deshalb spreche ich das hier ja auch ab und zu an. in der hitze der diskussion fällt es sicherlich schwer, dass anzunehmen. aber vielleicht solltest du dir das noch mal überlegen. ich denke mal, es ist alles gesagt.

Ilja

[Ludger]

Hi,

vielleicht solltest du dir noch mal vor augen führen, dass du mich mit deinem link überzeugen wolltest, was relationen sind.

hmmja, Relationen sind also Tabellen. Jede Tabelle ist also eine Relation. Darum heisst es ja auch relationale Datenbank.

[...] ich denke mal, es ist alles gesagt.

;-)

Gruss,
Ludger

[Ilja]

yo,

hmmja, Relationen sind also Tabellen. Jede Tabelle ist also eine Relation. Darum heisst es ja auch relationale Datenbank.

genau, und um noch mal genauer zu sagen, warum man das überhaupt relational nennt, ist weniger der bezug von einer tabelle zu einer anderen, sondern der bezug innerhalb einer tabelle der spalten mit den zeilen, quasi die typische zweidimensionalle darstellung einer tabelle ist damit gemeint.

Ilja

[Ludger]

Hi,

genau, und um noch mal genauer zu sagen, warum man das überhaupt relational nennt, ist weniger der bezug von einer tabelle zu einer anderen, sondern der bezug innerhalb einer tabelle der spalten mit den zeilen, quasi die typische zweidimensionalle darstellung einer tabelle ist damit gemeint.

sind ISAM-Datenbanken auch relational?

Gruss,
Ludger

[Ilja]

yo,

sind ISAM-Datenbanken auch relational?

ich würde mal pauschal behaupten, alle datenbanken in form von tabellen sind relationale datenbanken. nach unserer diksussion würde das ja auch irgendwie logisch klingen....

Ilja

[Struppi]

Hmm, ich lese dort auch:
Sie fassen die Daten bestimmter Zusammenhänge zu Gruppen zusammen, den Diskursbereichen. Diese Gruppen sind im Prinzip wieder Tabellen.

Klingt für mich eindeutig.

richtig, Gruppen von Relationen sind Tabellen, eben Relationentabellen. Eine Relation ist natuerlich keine Tabelle.

Wo steht dort was von Gruppen von Relationen?

Die Relation fasst Daten zu Gruppen zusammen und diese Gruppen sind im Prinzip Tabellen.

Struppi.

[roebert stumpe]

ich sehe dort nur, dass er mit anderen worten das schreibt, was ich gesagt habe, was relationen in bezug auf datenbanken betrifft. tupel sind nun mal tabellen.

lol

in einer ordentlichen DB sind Tupel einzelen Zeilen/Datensaetze einer Tabelle

[Ilja]

yo,

in einer ordentlichen DB sind Tupel einzelen Zeilen/Datensaetze einer Tabelle

ein tupel datensatz, mehrer tupel tabelle.

Ilja

[Ludger]

Hi,

in einer ordentlichen DB sind Tupel einzelen Zeilen/Datensaetze einer Tabelle

ein tupel datensatz, mehrer tupel tabelle.

und sind Relationen nun eher Datensaetze oder Datentabellen?

Gruss,
Ludger

[Ilja]

yo,

und sind Relationen nun eher Datensaetze oder Datentabellen?

in bezug auf datenbanken sind relationen tabellen, wie bereits gesagt wurde. beziehungen sind relationships....

Ilja

[Ilja]

yo,

um der diksussion ein ende zu bereiten, ein zitat aus deinem link....

relationale Datenbank: Hier werden alle Daten in Relationen, also Tabellen, dargestellt.....

Quelle: M+T Computerlexikon

Ilja

[fk]

Es gibt eine Tabelle company (company_id) und eine Tabelle object
(object_id)

company zu objekt = 1:n ???

Eine company kann mehrere Objekte haben. Die Relationen werden in der Tabelle rel_company_object gespeichert.

warum rel_company_object dazwischen ?? das macht man bei m:n strukturen. defacto hast du company 1:n rel_company_object und rel_company_object n:1 objekt.

daher wirst du ohne subselect nicht auskommen.

Suche alle Datensätze aus Tabelle company, die mit einem bestimmten Objekt verknüpft sind und für die es in der Tabelle object genau eine Relation gibt.

das geht nicht, ohne den COUNT zu bilden und die anderen spalten zu gruppieren.

ich glaube, daß die datenstruktur falsch ist. ordne diese neu (1:n) und stelle die frage bei bedarf nochmal.

[Ilja]

yo,

warum rel_company_object dazwischen ?? das macht man bei m:n strukturen. defacto hast du company 1:n rel_company_object und rel_company_object n:1 objekt.

da schiesst einer ein wenig zu schnell, so wie george busch. es ist zwar möglich, dass es sich um eine n:m beziehung handelt. aber genauso möglich, dass es nur eine 1:n beziehung ist, sprich jedes obejkt hat seinen eigenen hersteller.

daher wirst du ohne subselect nicht auskommen.

behauptung ohne gründe zu nennen...

Suche alle Datensätze aus Tabelle company, die mit einem bestimmten Objekt verknüpft sind und für die es in der Tabelle object genau eine Relation gibt.

die diskussion was eine relation ist hatten wir gerade.

Ilja

[fk]

warum rel_company_object dazwischen ?? das macht man bei m:n strukturen. defacto hast du company 1:n rel_company_object und rel_company_object n:1 objekt.

da schiesst einer ein wenig zu schnell, so wie george busch. es ist zwar möglich, dass es sich um eine n:m beziehung handelt. aber genauso möglich, dass es nur eine 1:n beziehung ist, sprich jedes obejkt hat seinen eigenen hersteller.

erst überlegen, dann handeln. 1:n : n:1 sind 2 baumstrukturen, welche an den blättern zusammentreffen, daher m:n. ob so ein baum nur eine ausprägung (blatt) hat, spielt hier keine rolle, da dies formell nicht erlaubt ist.

daher wirst du ohne subselect nicht auskommen.

behauptung ohne gründe zu nennen...

eine m:n struktur kann nicht mit einem select gelesen werden, da ein select immer von oben nach unten in einem baum abläuft. da sich hier 2 bäume an den blättern treffen, muß jeder baum mit einem eigenen select durchforstet werden.

Suche alle Datensätze aus Tabelle company, die mit einem bestimmten Objekt verknüpft sind und für die es in der Tabelle object genau eine Relation gibt.

die diskussion was eine relation ist hatten wir gerade.

???????????????????????????
ich habe das wort 'relation' nicht benutzt !! wenn du wissen möchtest was das ist, geh doch mal googeln.

[Ilja]

yo,

ich denke mal, dieser thread ist nicht gerade mein meisterwerk. aber so wie es in den wald hinein schallt, so.....

erst überlegen, dann handeln. 1:n : n:1 sind 2 baumstrukturen, welche an den blättern zusammentreffen, daher m:n. ob so ein baum nur eine ausprägung (blatt) hat, spielt hier keine rolle, da dies formell nicht erlaubt ist.

ich versuch mal zu überlegen. die diskussion, ob es sich um eine n:m oder 1:n beziehung handelt hatten wir schon ein wenig weiter unten. laut seinen tabellen handelt es sich um n:m, laut seinen aussagen aber um 1:n. also lassen wir das mal offen.

eine m:n struktur kann nicht mit einem select gelesen werden, da ein select immer von oben nach unten in einem baum abläuft.

ich wüsste nicht, warum man nicht einen select über n:m beziehungen bilden kann. vielleicht sehe ich ja den wald vor lauter bäumen nicht mehr. mich wundert aber immer, das leute behaupten, was alles nicht geht, nur weil sie es nicht können.

ich habe das wort 'relation' nicht benutzt !! wenn du wissen möchtest was das ist, geh doch mal googeln.

yo, hier ein zitat von dir:

Suche alle Datensätze aus Tabelle company, die mit einem bestimmten Objekt verknüpft sind und für die es in der Tabelle object genau eine -----> Relation <------- gibt.

Ilja

[Ludger]

Hi,

yo, hier ein zitat von dir:

Suche alle Datensätze aus Tabelle company, die mit einem bestimmten Objekt verknüpft sind und für die es in der Tabelle object genau eine -----> Relation <------- gibt.

Du wuerdest anraten statt Relation Beziehung zu verwenden und statt Tabelle Relation? Ich werde es mal damit versuchen, mal schauen, ob ich damit i.p. Verstaendigung durchkomme.

Gruss,
Ludger

[Ilja]

yo,

Du wuerdest anraten statt Relation Beziehung zu verwenden und statt Tabelle Relation? Ich werde es mal damit versuchen, mal schauen, ob ich damit i.p. Verstaendigung durchkomme.

es spielt keine rolle, ob man relation oder tabelle sagt. in beuzg auf datenbanken ist beides das gleiche. das kann sich jeder selbst ausssuchen. nur relationen sind keine beziehungen von tabellen, das sind relationships.

Ilja

[fk]

ich versuch mal zu überlegen. die diskussion, ob es sich um eine n:m oder 1:n beziehung handelt hatten wir schon ein wenig weiter unten. laut seinen tabellen handelt es sich um n:m, laut seinen aussagen aber um 1:n. also lassen wir das mal offen.

die daten können durchaus 1:n : 1:n sein. das spielt aber keine rolle.
ein baum hat immer eine wurzel. dort wird eingestiegen. nimmt man die blätter, gibt es soviele einstiegspunkte, daß man sich nicht entscheiden kann, welchen man nehmen soll.

ich wüsste nicht, warum man nicht einen select über n:m beziehungen bilden kann. vielleicht sehe ich ja den wald vor lauter bäumen nicht mehr. mich wundert aber immer, das leute behaupten, was alles nicht geht, nur weil sie es nicht können.

sicherlich kann man selects über m:n bilden, nur wenn dann weitere tabellen drangehängt werden, welche über n:1 eingestiegen werden muß, erkennen viele sql server das aus performancegründen nicht an und melden fehler.

ich habe das wort 'relation' nicht benutzt !! wenn du wissen möchtest was das ist, geh doch mal googeln.

yo, hier ein zitat von dir:

Suche alle Datensätze aus Tabelle company, die mit einem bestimmten Objekt verknüpft sind und für die es in der Tabelle object genau eine -----> Relation <------- gibt.

schau nochmal in das original.
die mit »» gekennzeichneten texte sind das schwarz. meine text ist blau. oder hast du einen schwarz/weiß browser???

[Ludger]

Hi,

sicherlich kann man selects über m:n bilden, nur wenn dann weitere tabellen drangehängt werden, welche über n:1 eingestiegen werden muß, erkennen viele sql server das aus performancegründen nicht an und melden fehler.

welche Fehler melden die kleinen Datenserver denn so?

"Ich kann nicht mehr - zu viele Daten." oder "n zu m Beziehung erkannt - Process failed"?

Gruss,
Ludger

[fk]

welche Fehler melden die kleinen Datenserver denn so?

"Ich kann nicht mehr - zu viele Daten." oder "n zu m Beziehung erkannt - Process failed"?

wie weiter oben schon gesagt, wird dies formell festgestellt. daher versucht der server erst nicht, die abfrage auszuführen.

mit access läßt sich so etwas immer schön ausprobieren.