From u.kretschmer.mysql.4t2 at bergruf.de Mon May 21 21:03:12 2007 From: u.kretschmer.mysql.4t2 at bergruf.de (Ulrich Kretschmer) Date: Mon, 21 May 2007 21:03:12 +0200 Subject: verwickelte SQL-Abfrage mit JOIN's Message-ID: <200705212103.12828.u.kretschmer.mysql.4t2@bergruf.de> Hallo zusammen, die folgende Abfrage SELECT familyID, w.personID, w.lastname, w.firstname, et.tag, et.description, e.info FROM tng_families AS f INNER JOIN tng_people AS w ON (f.wife=w.personID AND f.gedcom=w.gedcom) LEFT JOIN tng_events AS e ON (w.personID=e.persfamID AND w.gedcom=e.gedcom) LEFT JOIN tng_eventtypes AS et ON e.eventtypeID=et.eventtypeID; verbindet die Tabellen tng_eventypes -> tng_events -> tng_people -> tng_families und soll so modifiziert werden, daß alle Personen geliefert werden, die das "event" Ehename *nicht* zugeordnet haben und ansonsten entweder gar keine "events" haben (et.tag=NULL) oder auch irgendwelche anderen (description<>"Ehename"). Einige Beispiele bzw. Fallunterscheidungen zur Verdeutlichung: +----------+----------+----------+----------------------+------+-------------+--------------+ | familyID | personID | lastname | firstname | tag | description | info | +----------+----------+----------+----------------------+------+-------------+--------------+ | F11342 | I4917 | Meyer | | NULL | NULL ^ hat gar keine Ereignisse (et.tag=NULL) zugeordnet => solche Zeilen sollen geliefert werden | F13983 | I34643 | Meyer | Auguste Rosine | EVEN | Rufname | Rosine | | F13983 | I34643 | Meyer | Auguste Rosine | EVEN | Ehename | Müller | ^ hat bereits ein Ereignis Ehename zugeordnet (et.tag="EVEN" AND description="Ehename") => zu einer solchen Person sollen keine Zeilen geliefert werden | F13306 | I32755 | Meyer | Gisela Luise | OCCU | | einBeruf | | F13306 | I32755 | Meyer | Gisela Luise | EVEN | Rufname | Gisela | ^ hat irgendwelche anderen Ereignisse zugeordnet (et.tag<>NULL), aber keinen Ehenamen => diese Zeilen sollen geliefert werden (wobei es an sich genügen würde, pro Person (personID) nur eine Zeile zu liefern). Mit so einer Abfrage steh ich auf dem Schlauch... vor allem mit dem zweiten und dritten Fall - zu einer Person kann es "n" events geben, aber erst beim letzten weiß man, ob nicht doch ein Ehename dabeigewesen ist, sodaß die vorhergehenden Zeilen eigentlich gar nicht interessiert haben. Ich habe die grobe Vorstellung, daß man die ganze Abfrage irgendwie (?) verdoppeln muß, um zu jeder Zeile (w.personID) nochmals eine Spalte mit entweder et.description="Ehename" oder NULL zu haben, wonach man dann alle Zeilen mit "Ehename" in dieser zusätzlichen Spalte unterdrückt und der gewünschte Rest übrig bleibt. Aber wie kriege ich diese zusätzliche Spalte hin? Oder vielleicht geht es ja ganz anders und viel einfacher... Mit Dank im Voraus Ulrich _______________________________________________ Allgemeine Infos zur Liste: http://www.4t2.com/mysql/ Verwaltung: https://lists.4t2.com/cgi-bin/mailman/listinfo/mysql-de From lists at sebastianmendel.de Mon May 21 21:48:17 2007 From: lists at sebastianmendel.de (Sebastian Mendel) Date: Mon, 21 May 2007 21:48:17 +0200 Subject: verwickelte SQL-Abfrage mit JOIN's In-Reply-To: <200705212103.12828.u.kretschmer.mysql.4t2@bergruf.de> References: <200705212103.12828.u.kretschmer.mysql.4t2@bergruf.de> Message-ID: <4651F781.2090206@sebastianmendel.de> Ulrich Kretschmer schrieb: > Hallo zusammen, > > die folgende Abfrage > > SELECT familyID, w.personID, w.lastname, w.firstname, et.tag, et.description, > e.info FROM tng_families AS f > INNER JOIN tng_people AS w ON (f.wife=w.personID AND f.gedcom=w.gedcom) > LEFT JOIN tng_events AS e ON (w.personID=e.persfamID AND w.gedcom=e.gedcom) > LEFT JOIN tng_eventtypes AS et ON e.eventtypeID=et.eventtypeID; > > verbindet die Tabellen > tng_eventypes -> tng_events -> tng_people -> tng_families > und soll so modifiziert werden, daß alle Personen geliefert werden, die das > "event" Ehename *nicht* zugeordnet haben und ansonsten entweder gar keine > "events" haben (et.tag=NULL) oder auch irgendwelche anderen > (description<>"Ehename"). ich glaub ich hab null verstanden was du willst, vielleciht liegt es ander Uhrzeit ... aber probier doch mla sowas wie ... LEFT JOIN tng_eventtypes AS et ON e.eventtypeID = et.eventtypeID AND et.tag = NULL AND et.description = 'Ehename'; vielelicht kannst du dein Query das nächste mal ja auch etwas in 'Form' bringen damit es sich leichter liest ... -- Sebastian _______________________________________________ Allgemeine Infos zur Liste: http://www.4t2.com/mysql/ Verwaltung: https://lists.4t2.com/cgi-bin/mailman/listinfo/mysql-de From rico at netbreaker.de Tue May 22 08:36:59 2007 From: rico at netbreaker.de (Rico Koerner) Date: Tue, 22 May 2007 08:36:59 +0200 Subject: verwickelte SQL-Abfrage mit JOIN's In-Reply-To: <4651F781.2090206@sebastianmendel.de> References: <200705212103.12828.u.kretschmer.mysql.4t2@bergruf.de> <4651F781.2090206@sebastianmendel.de> Message-ID: <46528F8B.3060102@netbreaker.de> Sebastian Mendel schrieb: > Ulrich Kretschmer schrieb: >> Hallo zusammen, >> >> die folgende Abfrage >> >> SELECT familyID, w.personID, w.lastname, w.firstname, et.tag, et.description, >> e.info FROM tng_families AS f >> INNER JOIN tng_people AS w ON (f.wife=w.personID AND f.gedcom=w.gedcom) >> LEFT JOIN tng_events AS e ON (w.personID=e.persfamID AND w.gedcom=e.gedcom) >> LEFT JOIN tng_eventtypes AS et ON e.eventtypeID=et.eventtypeID; >> >> verbindet die Tabellen >> tng_eventypes -> tng_events -> tng_people -> tng_families >> und soll so modifiziert werden, daß alle Personen geliefert werden, die das >> "event" Ehename *nicht* zugeordnet haben und ansonsten entweder gar keine >> "events" haben (et.tag=NULL) oder auch irgendwelche anderen >> (description<>"Ehename"). > > ich glaub ich hab null verstanden was du willst, vielleciht liegt es ander > Uhrzeit ... > > aber probier doch mla sowas wie > > ... > LEFT JOIN > tng_eventtypes AS et > ON e.eventtypeID = et.eventtypeID > AND et.tag = NULL > AND et.description = 'Ehename'; Selektierende Parameter sollten nicht im JOIN sondern bei WHERE stehen, also WHERE et.tag IS NULL OR ... vor allem auch OR, nicht AND denn es soll ja auch Datensätze liefern in denen et.tag NOT NULL ist dafür aber et.description != 'Ehename' Allerdings weiß ich nicht, wie man letzteres rausfiltert. Als Ansatz hab ich noch GROUP BY gesehen, aber es ist nicht garantiert, daß der DS mit 'Ehename' der letzte ist. Ich frage mich aber gerade ob die Tabellen ausreichend normalisiert sind. Oder waren die Beispielzeilen schon die Ausgabe? Gruß Rico _______________________________________________ Allgemeine Infos zur Liste: http://www.4t2.com/mysql/ Verwaltung: https://lists.4t2.com/cgi-bin/mailman/listinfo/mysql-de From lists at sebastianmendel.de Tue May 22 09:04:20 2007 From: lists at sebastianmendel.de (Sebastian Mendel) Date: Tue, 22 May 2007 09:04:20 +0200 Subject: verwickelte SQL-Abfrage mit JOIN's In-Reply-To: <46528F8B.3060102@netbreaker.de> References: <200705212103.12828.u.kretschmer.mysql.4t2@bergruf.de> <4651F781.2090206@sebastianmendel.de> <46528F8B.3060102@netbreaker.de> Message-ID: <465295F4.50903@sebastianmendel.de> Rico Koerner schrieb: > Sebastian Mendel schrieb: >> Ulrich Kretschmer schrieb: >>> Hallo zusammen, >>> >>> die folgende Abfrage >>> >>> SELECT familyID, w.personID, w.lastname, w.firstname, et.tag, et.description, >>> e.info FROM tng_families AS f >>> INNER JOIN tng_people AS w ON (f.wife=w.personID AND f.gedcom=w.gedcom) >>> LEFT JOIN tng_events AS e ON (w.personID=e.persfamID AND w.gedcom=e.gedcom) >>> LEFT JOIN tng_eventtypes AS et ON e.eventtypeID=et.eventtypeID; >>> >>> verbindet die Tabellen >>> tng_eventypes -> tng_events -> tng_people -> tng_families >>> und soll so modifiziert werden, daß alle Personen geliefert werden, die das >>> "event" Ehename *nicht* zugeordnet haben und ansonsten entweder gar keine >>> "events" haben (et.tag=NULL) oder auch irgendwelche anderen >>> (description<>"Ehename"). >> ich glaub ich hab null verstanden was du willst, vielleciht liegt es ander >> Uhrzeit ... >> >> aber probier doch mla sowas wie >> >> ... >> LEFT JOIN >> tng_eventtypes AS et >> ON e.eventtypeID = et.eventtypeID >> AND et.tag = NULL >> AND et.description = 'Ehename'; > > Selektierende Parameter sollten nicht im JOIN sondern bei WHERE stehen, also Wer sagt das? Und vor allem wieso? (Ich kenne diese Aussage, halte sie aber für unbegründet und einen Mythos) Außerdem ist es kein Dogma sondern höchstens ein Paradigma. Und zu guter letzte, es hilft dir zu deinem Ergebnis (natürlich richtig formuliert ;-) und nicht wie ich oben falsch) > die das > "event" Ehename *nicht* zugeordnet haben und ansonsten entweder gar keine > "events" haben (et.tag=NULL) oder auch irgendwelche anderen > (description<>"Ehename"). LEFT JOIN tng_eventtypes AS et ON e.eventtypeID = et.eventtypeID AND et.tag = 'EVEN' AND et.description = 'Ehename'; (alle ohne einen event Ehename haben jetzt NULL in den et-Feldern) > WHERE et.tag IS NULL OR ... > > vor allem auch OR, nicht AND denn es soll ja auch Datensätze liefern in > denen et.tag NOT NULL ist dafür aber et.description != 'Ehename' nein nein, du willst alle außer die mit dem event Ehename also, verknüpfts die deine Personen NUR mit genau diesem Ausschlusskriterium und filterst alle ungleich NULL aus (HAVING IS_NULL(et.tag)) > Ich frage mich aber gerade ob die Tabellen ausreichend normalisiert > sind. Oder waren die Beispielzeilen schon die Ausgabe? ja, das sieht man von hieraus nicht ... ;-) -- Sebastian Mendel www.sebastianmendel.de _______________________________________________ Allgemeine Infos zur Liste: http://www.4t2.com/mysql/ Verwaltung: https://lists.4t2.com/cgi-bin/mailman/listinfo/mysql-de From lists at sebastianmendel.de Tue May 22 09:09:59 2007 From: lists at sebastianmendel.de (Sebastian Mendel) Date: Tue, 22 May 2007 09:09:59 +0200 Subject: verwickelte SQL-Abfrage mit JOIN's In-Reply-To: <465295F4.50903@sebastianmendel.de> References: <200705212103.12828.u.kretschmer.mysql.4t2@bergruf.de> <4651F781.2090206@sebastianmendel.de> <46528F8B.3060102@netbreaker.de> <465295F4.50903@sebastianmendel.de> Message-ID: <46529747.404@sebastianmendel.de> Sebastian Mendel schrieb: > Rico Koerner schrieb: >> Selektierende Parameter sollten nicht im JOIN sondern bei WHERE stehen, also > > [...] > > LEFT JOIN > tng_eventtypes AS et > ON e.eventtypeID = et.eventtypeID > AND et.tag = 'EVEN' > AND et.description = 'Ehename'; > > (alle ohne einen event Ehename haben jetzt NULL in den et-Feldern) p.s. du kannst natürlich auch, wenn dir das obige Verfahren doch gar zu wider ist, auch ein Subselect (Subquery, derived Table oder was auch immer) nehmen ... LEFT JOIN (SELECT * FROM tng_eventtypes WHERE et.tag = 'EVEN' AND et.description = 'Ehename') AS et ON e.eventtypeID = et.eventtypeID ... -- Sebastian Mendel www.sebastianmendel.de _______________________________________________ Allgemeine Infos zur Liste: http://www.4t2.com/mysql/ Verwaltung: https://lists.4t2.com/cgi-bin/mailman/listinfo/mysql-de From rico at netbreaker.de Tue May 22 09:45:05 2007 From: rico at netbreaker.de (Rico Koerner) Date: Tue, 22 May 2007 09:45:05 +0200 Subject: verwickelte SQL-Abfrage mit JOIN's In-Reply-To: <465295F4.50903@sebastianmendel.de> References: <200705212103.12828.u.kretschmer.mysql.4t2@bergruf.de> <4651F781.2090206@sebastianmendel.de> <46528F8B.3060102@netbreaker.de> <465295F4.50903@sebastianmendel.de> Message-ID: <46529F81.60508@netbreaker.de> Sebastian Mendel schrieb: > Rico Koerner schrieb: >> Selektierende Parameter sollten nicht im JOIN sondern bei WHERE stehen, also > > Wer sagt das? Und vor allem wieso? > (Ich kenne diese Aussage, halte sie aber für unbegründet und einen Mythos) Das sagt die MySQL-Dokumentation, das wieso solltest du dann wohl an die Entwickler stellen. ;-) Ich kann mir dafür mehrere Gründe vorstellen: - bessere Übersichlichkeit (damit aber nicht wirklich relevant) - Performanceunterschiede in der Ausführung (noch nicht evaluiert) - wichtig für den Parser? - einfach nur wegen dem SQL-Standard? - Joins sind für die Verknüpfung von Tabellen zuständig. Ich kenn die MyQSL-Internas nicht so genau und es funktioniert auch im Join, zumindest sofern sich die Where-Bedingung auf die beiden Tabellen des Joins bezieht. Den genauen Grund kennen wohl nur die Entwickler. > Außerdem ist es kein Dogma sondern höchstens ein Paradigma. > > Und zu guter letzte, es hilft dir zu deinem Ergebnis (natürlich richtig > formuliert ;-) und nicht wie ich oben falsch) > > >> die das >> "event" Ehename *nicht* zugeordnet haben und ansonsten entweder gar keine >> "events" haben (et.tag=NULL) oder auch irgendwelche anderen >> (description<>"Ehename"). > > LEFT JOIN > tng_eventtypes AS et > ON e.eventtypeID = et.eventtypeID > AND et.tag = 'EVEN' > AND et.description = 'Ehename'; > > (alle ohne einen event Ehename haben jetzt NULL in den et-Feldern) > >> WHERE et.tag IS NULL OR ... >> >> vor allem auch OR, nicht AND denn es soll ja auch Datensätze liefern in >> denen et.tag NOT NULL ist dafür aber et.description != 'Ehename' > > nein nein, du willst alle außer die mit dem event Ehename Doch, das OR ist schon richtig, er will alle ohne Event (et.tag IS NULL) und alle mit ((et.tag NOT NULL) AND (et.description != 'Ehename')) Die Bedingung lautete nicht et.tag = 'EVEN', da gabs auch noch ein 'OCCU' als möglichen Wert. Wieviel gibts da wohl noch? Daher auch meine Prüfung auf 1. et.tag IS NULL (die wollte er alle und dort steht auch nix von et.description = 'Ehename') 2. alle anderen, in denen nicht 'Ehename' steht. Ein AND dazwischen würde ja nur bei et.tag IS NOT NULL nach den anderen suchen. > also, verknüpfts die deine Personen NUR mit genau diesem Ausschlusskriterium > und filterst alle ungleich NULL aus (HAVING IS_NULL(et.tag)) Ach ja, HAVING gibts ja auch noch. ;-) Gruß Rico _______________________________________________ Allgemeine Infos zur Liste: http://www.4t2.com/mysql/ Verwaltung: https://lists.4t2.com/cgi-bin/mailman/listinfo/mysql-de From rico at netbreaker.de Tue May 22 09:48:41 2007 From: rico at netbreaker.de (Rico Koerner) Date: Tue, 22 May 2007 09:48:41 +0200 Subject: verwickelte SQL-Abfrage mit JOIN's In-Reply-To: <46529747.404@sebastianmendel.de> References: <200705212103.12828.u.kretschmer.mysql.4t2@bergruf.de> <4651F781.2090206@sebastianmendel.de> <46528F8B.3060102@netbreaker.de> <465295F4.50903@sebastianmendel.de> <46529747.404@sebastianmendel.de> Message-ID: <4652A059.3020507@netbreaker.de> Sebastian Mendel schrieb: > Sebastian Mendel schrieb: > > p.s. du kannst natürlich auch, wenn dir das obige Verfahren doch gar zu > wider ist, auch ein Subselect (Subquery, derived Table oder was auch immer) > nehmen Ja, an einen Subselect hab ich auch schon gedacht, aber mit den dürftigen Informationen über die Tabelleninhalte hab ich mich hier lieber etwas zurückgehalten. Außerdem hab ich Subselects bisher möglichst gemieden (wohl eher historisch bedingt). Rico _______________________________________________ Allgemeine Infos zur Liste: http://www.4t2.com/mysql/ Verwaltung: https://lists.4t2.com/cgi-bin/mailman/listinfo/mysql-de From lists at sebastianmendel.de Tue May 22 09:56:41 2007 From: lists at sebastianmendel.de (Sebastian Mendel) Date: Tue, 22 May 2007 09:56:41 +0200 Subject: verwickelte SQL-Abfrage mit JOIN's In-Reply-To: <46529F81.60508@netbreaker.de> References: <200705212103.12828.u.kretschmer.mysql.4t2@bergruf.de> <4651F781.2090206@sebastianmendel.de> <46528F8B.3060102@netbreaker.de> <465295F4.50903@sebastianmendel.de> <46529F81.60508@netbreaker.de> Message-ID: <4652A239.7020109@sebastianmendel.de> Rico Koerner schrieb: > Sebastian Mendel schrieb: >> Rico Koerner schrieb: >>> Selektierende Parameter sollten nicht im JOIN sondern bei WHERE stehen, also >> Wer sagt das? Und vor allem wieso? >> (Ich kenne diese Aussage, halte sie aber für unbegründet und einen Mythos) > > Das sagt die MySQL-Dokumentation, ich weiß, aber das ist doch kein Grund ... ;-) ... was alles in irgendwelchen Büchern steht ... > das wieso solltest du dann wohl an die Entwickler stellen. ;-) > Ich kann mir dafür mehrere Gründe vorstellen: > - bessere Übersichlichkeit (damit aber nicht wirklich relevant) nö, ich will nur die betimmtn Zeilen von der Tabelle, steht also in direktem Zusammenhang > - Performanceunterschiede in der Ausführung (noch nicht evaluiert) dieser Punkt spricht eher dafür, aber auch nicht getested > - wichtig für den Parser? > - einfach nur wegen dem SQL-Standard? > - Joins sind für die Verknüpfung von Tabellen zuständig. eben, und hier sage ich welche Zeilen verknüpft werden sollen, nämlich nur betimmte >>> WHERE et.tag IS NULL OR ... >>> >>> vor allem auch OR, nicht AND denn es soll ja auch Datensätze liefern in >>> denen et.tag NOT NULL ist dafür aber et.description != 'Ehename' >> nein nein, du willst alle außer die mit dem event Ehename > > Doch, das OR ist schon richtig, er will alle ohne Event (et.tag IS NULL) > und alle mit ((et.tag NOT NULL) AND (et.description != 'Ehename')) > > Die Bedingung lautete nicht et.tag = 'EVEN', da gabs auch noch ein > 'OCCU' als möglichen Wert. Wieviel gibts da wohl noch? doch, ist richtig! ;-) also hole ich ALLE Personen und ordne denen das EVENT 'Ehename' zu wenn sie das haben, anonsten NULL, und am Ende filtere ich alle aus die nicht NULL haben (HAVING) -- Sebastian Mendel www.sebastianmendel.de _______________________________________________ Allgemeine Infos zur Liste: http://www.4t2.com/mysql/ Verwaltung: https://lists.4t2.com/cgi-bin/mailman/listinfo/mysql-de From mysql at universalware.de Tue May 22 10:14:45 2007 From: mysql at universalware.de (=?iso-8859-1?Q?Andreas_M=FCller?=) Date: Tue, 22 May 2007 10:14:45 +0200 Subject: verwickelte SQL-Abfrage mit JOIN's In-Reply-To: <465295F4.50903@sebastianmendel.de> References: <200705212103.12828.u.kretschmer.mysql.4t2@bergruf.de> <4651F781.2090206@sebastianmendel.de><46528F8B.3060102@netbreaker.de> <465295F4.50903@sebastianmendel.de> Message-ID: <082001c79c49$42097450$1400a8c0@nbandreas> Hallo Sebastian, > Wer sagt das? Und vor allem wieso? > (Ich kenne diese Aussage, halte sie aber für unbegründet und > einen Mythos) > > Außerdem ist es kein Dogma sondern höchstens ein Paradigma. hier muss man fein unterscheiden. Bei INNER JOIN's ist das an sich egal ob man die Bedingungen nach ON in den JOIN schreibt oder ins WHERE. Bei LEFT JOIN's ist das aber ein großer Unterschied: Alles was hinter ON im JOIN steht ist die "Join-Condition" - sprich unter welchen bedingunge gejoint wird oder nicht. Gruß, Andreas _______________________________________________ Allgemeine Infos zur Liste: http://www.4t2.com/mysql/ Verwaltung: https://lists.4t2.com/cgi-bin/mailman/listinfo/mysql-de From lists at sebastianmendel.de Tue May 22 10:44:24 2007 From: lists at sebastianmendel.de (Sebastian Mendel) Date: Tue, 22 May 2007 10:44:24 +0200 Subject: verwickelte SQL-Abfrage mit JOIN's In-Reply-To: <082001c79c49$42097450$1400a8c0@nbandreas> References: <200705212103.12828.u.kretschmer.mysql.4t2@bergruf.de> <4651F781.2090206@sebastianmendel.de><46528F8B.3060102@netbreaker.de> <465295F4.50903@sebastianmendel.de> <082001c79c49$42097450$1400a8c0@nbandreas> Message-ID: <4652AD68.8020701@sebastianmendel.de> Andreas Müller schrieb: > Hallo Sebastian, > >> Wer sagt das? Und vor allem wieso? >> (Ich kenne diese Aussage, halte sie aber für unbegründet und >> einen Mythos) >> >> Außerdem ist es kein Dogma sondern höchstens ein Paradigma. > > hier muss man fein unterscheiden. Bei INNER JOIN's ist das an sich egal ob > man die Bedingungen nach ON in den JOIN schreibt oder ins WHERE. > Bei LEFT JOIN's ist das aber ein großer Unterschied: Alles was hinter ON im > JOIN steht ist die "Join-Condition" - sprich unter welchen bedingunge > gejoint wird oder nicht. Und genau darum ging es, ich will genau festlegen welche Zeilen verbunden werden und welche nicht. -- Sebastian Mendel www.sebastianmendel.de _______________________________________________ Allgemeine Infos zur Liste: http://www.4t2.com/mysql/ Verwaltung: https://lists.4t2.com/cgi-bin/mailman/listinfo/mysql-de From a.balke at digiden.de Tue May 22 11:35:58 2007 From: a.balke at digiden.de (andreas balke) Date: Tue, 22 May 2007 11:35:58 +0200 Subject: verwickelte SQL-Abfrage mit JOIN's Message-ID: <4652B97E.7020603@digiden.de> hallo, leider kann ich das komplette statement nicht bauen, da die anderen tabellen fehlen. ich nehme an, das hier ist die tng_people. meiner meinung nach solltest du diese tabelle einfach doppelt rein joinen: LEFT JOIN tng_people AS wExclude ON (f.wife=w.personID AND f.gedcom=w.gedcom AND et.tag="EVEN" AND description="Ehename") INNER JOIN tng_people AS wInclude ON (f.wife=w.personID AND f.gedcom=w.gedcom AND ( ( et.tag IS NOT NULL AND description<>"Ehename" ) AND !( et.tag="EVEN" AND description="Ehename" ) /* überflüssig, aber sicher ist sicher ;) */ ) ) da bei dem ersten join die richtigen zeilen NULL haben, setzt du eine condition hinten dran: WHERE wExclude.personID IS NULL wenn du nun jede person nur einmal haben willst, sagst du am ende: GROUP BY wInclude.personID ansonsten bekommst du auch die mehrmals, die in deiner zweiten condition (das inner join) mehrmals auftauchen. subselects solltest du vermeiden, da die immer langsam sind. währenddessen filtern conditionen in inner joins das resultset schon gut vor und geben dem where wenig zu tun. nicht zu vergessen, daß die filterfelder in den joins indiziert sein müssen :) beste grüße, andi -- Andreas Balke // Lead Developer Digiden GmbH • Agentur für Kommunikationslösungen In der Backfabrik • Saarbrückerstraße 37b • D-10405 Berlin Fon: +49 (30) 446 749 425 • Fax: +49 (30) 446 749 479 www.digiden.de -------------- nächster Teil -------------- Ein Dateianhang mit Binärdaten wurde abgetrennt... Dateiname : smime.p7s Dateityp : application/x-pkcs7-signature Dateigröße : 3236 bytes Beschreibung: S/MIME Cryptographic Signature URL : http://lists.mushaake.org/pipermail/mysql-de/attachments/20070522/213f88c9/attachment.bin -------------- nächster Teil -------------- _______________________________________________ Allgemeine Infos zur Liste: http://www.4t2.com/mysql/ Verwaltung: https://lists.4t2.com/cgi-bin/mailman/listinfo/mysql-de From u.kretschmer.mysql.4t2 at bergruf.de Wed May 23 00:12:01 2007 From: u.kretschmer.mysql.4t2 at bergruf.de (Ulrich Kretschmer) Date: Wed, 23 May 2007 00:12:01 +0200 Subject: verwickelte SQL-Abfrage mit JOIN's In-Reply-To: <46528F8B.3060102@netbreaker.de> References: <200705212103.12828.u.kretschmer.mysql.4t2@bergruf.de> <4651F781.2090206@sebastianmendel.de> <46528F8B.3060102@netbreaker.de> Message-ID: <200705230012.01254.u.kretschmer.mysql.4t2@bergruf.de> Am Dienstag 22. Mai 2007 08:36 schrieb Rico Koerner: > Ich frage mich aber gerade ob die Tabellen ausreichend normalisiert > sind. Oder waren die Beispielzeilen schon die Ausgabe? Hallo, ja, die Beispielzeilen waren die Ausgabe der gezeigten (noch zu modifizierenden) Abfrage. Grüße Ulrich _______________________________________________ Allgemeine Infos zur Liste: http://www.4t2.com/mysql/ Verwaltung: https://lists.4t2.com/cgi-bin/mailman/listinfo/mysql-de From u.kretschmer.mysql.4t2 at bergruf.de Wed May 23 00:09:24 2007 From: u.kretschmer.mysql.4t2 at bergruf.de (Ulrich Kretschmer) Date: Wed, 23 May 2007 00:09:24 +0200 Subject: verwickelte SQL-Abfrage mit JOIN's In-Reply-To: <465295F4.50903@sebastianmendel.de> References: <200705212103.12828.u.kretschmer.mysql.4t2@bergruf.de> <46528F8B.3060102@netbreaker.de> <465295F4.50903@sebastianmendel.de> Message-ID: <200705230009.24221.u.kretschmer.mysql.4t2@bergruf.de> Hallo zusammen, Am Dienstag 22. Mai 2007 09:04 schrieb Sebastian Mendel: > LEFT JOIN > tng_eventtypes AS et > ON e.eventtypeID = et.eventtypeID > AND et.tag = 'EVEN' > AND et.description = 'Ehename'; > > (alle ohne einen event Ehename haben jetzt NULL in den et-Feldern) Beispielausgabe bis hierher: http://www.ahnendaten.de/ahnen/showreport.php?reportID=226 > nein nein, du willst alle außer die mit dem event Ehename > > also, verknüpfts die deine Personen NUR mit genau diesem > Ausschlusskriterium und filterst alle ungleich NULL aus (HAVING > IS_NULL(et.tag)) Beispielausgabe hierzu: http://www.ahnendaten.de/ahnen/showreport.php?reportID=227 D.h. damit verschwinden gegenüber dem ersten Beispiel zwar die Zeilen mit "Ehename", aber das ist es auch noch nicht ganz. Denn es sollen alle Zeilen zu denjenigen Personen, die bereits einen Ehenamen zugeordnet haben, nicht mehr erscheinen. Grüße Ulrich _______________________________________________ Allgemeine Infos zur Liste: http://www.4t2.com/mysql/ Verwaltung: https://lists.4t2.com/cgi-bin/mailman/listinfo/mysql-de From u.kretschmer.mysql.4t2 at bergruf.de Tue May 22 23:54:29 2007 From: u.kretschmer.mysql.4t2 at bergruf.de (Ulrich Kretschmer) Date: Tue, 22 May 2007 23:54:29 +0200 Subject: verwickelte SQL-Abfrage mit JOIN's In-Reply-To: <4652B97E.7020603@digiden.de> References: <4652B97E.7020603@digiden.de> Message-ID: <200705222354.30308.u.kretschmer.mysql.4t2@bergruf.de> Hallo, Am Dienstag 22. Mai 2007 11:35 schrieb andreas balke: > leider kann ich das komplette statement nicht bauen, da die anderen > tabellen fehlen. Die kompletten Tabellendefinitionen habe ich an den Schluß angehängt. (Ich hatte zunächst darauf verzichtet, da ziemlich umfangreich.) Um gleich der nächsten Frage zuvorzukommen - nein, ich habe diese Anwendung nicht programmiert. Ich versuche nur, die mich im Moment speziell interessierenden Daten aus der Datenbank herauszuziehen... > ich nehme an, das hier ist die tng_people. meiner > meinung nach solltest du diese tabelle einfach doppelt rein joinen: hm.... am besten schrittweise: 1) Ergebnisse meiner ursprünglichen Abfrage, beschränkt auf einige typische Beispieldaten: http://www.ahnendaten.de/ahnen/showreport.php?reportID=223 (Das PHP-Skript übersetzt die ursprünglichen Spaltenbezeichnungen z.T. ins Deutsche.) 2) Nun eine Weiterentwicklung mit doppelten Joins: SELECT familyID, w.personID, w.lastname, w.firstname, et.tag, et.description, e.info, et2.tag, et2.description, e2.info FROM tng_families AS f INNER JOIN tng_people AS w ON (f.wife=w.personID AND f.gedcom=w.gedcom) LEFT JOIN tng_events AS e ON (w.personID=e.persfamID AND w.gedcom=e.gedcom) LEFT JOIN tng_eventtypes AS et ON (e.eventtypeID=et.eventtypeID) LEFT JOIN tng_people AS w2 ON (f.wife=w2.personID AND f.gedcom=w2.gedcom) LEFT JOIN tng_events AS e2 ON (w.personID=e2.persfamID AND w.gedcom=e2.gedcom) LEFT JOIN tng_eventtypes AS et2 ON (e2.eventtypeID=et2.eventtypeID); wobei mir das etwas spanisch vorkommt, weil manche Personenzeilen verdoppelt werden (ich will nicht behaupten, daß ich das wirklich verstehe); Beispiel-Ergebnisse: http://www.ahnendaten.de/ahnen/showreport.php?reportID=224 > LEFT JOIN tng_people AS wExclude ON (f.wife=w.personID AND > f.gedcom=w.gedcom AND et.tag="EVEN" AND description="Ehename") INNER JOIN > tng_people AS wInclude ON (f.wife=w.personID AND f.gedcom=w.gedcom AND ( ( > et.tag IS NOT NULL AND description<>"Ehename" ) > AND !( et.tag="EVEN" AND description="Ehename" ) /* überflüssig, aber > sicher ist sicher ;) */ ) > ) 3) Nun habe ich versucht, die ergänzenden Bedingungen einzubauen (ob ich es aber richtig gemacht habe, ist zweifelhaft): SELECT familyID, w.personID, w.lastname, w.firstname, et.tag, et.description, e.info, w2.personID, et2.tag, et2.description, e2.info FROM tng_families AS f INNER JOIN tng_people AS w ON (f.wife=w.personID AND f.gedcom=w.gedcom) LEFT JOIN tng_events AS e ON (w.personID=e.persfamID AND w.gedcom=e.gedcom) LEFT JOIN tng_eventtypes AS et ON (e.eventtypeID=et.eventtypeID AND et.tag="EVEN" AND et.description="Ehename") LEFT JOIN tng_people AS w2 ON (f.wife=w2.personID AND f.gedcom=w2.gedcom) LEFT JOIN tng_events AS e2 ON (w.personID=e2.persfamID AND w.gedcom=e2.gedcom) LEFT JOIN tng_eventtypes AS et2 ON (e2.eventtypeID=et2.eventtypeID AND ((et2.tag IS NOT NULL AND et2.description<>"Ehename") AND !(et2.tag="EVEN" AND et2.description="Ehename"))) Beispiel-Ergebnisse: http://www.ahnendaten.de/ahnen/showreport.php?reportID=225 Das geht jetzt allmählich in die richtige Richtung, aber so ganz ist es immer noch nicht richtig - wie unterdrücke ich nun alle Zeilen zu denjenigen Personen, denen ein event "Ehename" zugeordnet ist? > da bei dem ersten join die richtigen zeilen NULL haben, setzt du eine > condition hinten dran: > > WHERE > wExclude.personID IS NULL Damit habe ich herumexperimentiert, aber ohne greifbares Ergebnis. Bis hierhin jedenfalls schon mal vielen Dank! Ulrich *************************************** CREATE TABLE `tng_people` (   `ID` int(11) NOT NULL auto_increment,   `gedcom` varchar(20) NOT NULL default '',   `personID` varchar(22) NOT NULL default '',   `lnprefix` varchar(25) NOT NULL default '',   `lastname` varchar(127) NOT NULL default '',   `firstname` varchar(127) NOT NULL default '',   `birthdate` varchar(50) NOT NULL default '',   `birthdatetr` date NOT NULL default '0000-00-00',   `sex` tinytext NOT NULL,   `birthplace` text NOT NULL,   `deathdate` varchar(50) NOT NULL default '',   `deathdatetr` date NOT NULL default '0000-00-00',   `deathplace` text NOT NULL,   `altbirthdate` varchar(50) NOT NULL default '',   `altbirthdatetr` date NOT NULL default '0000-00-00',   `altbirthplace` text NOT NULL,   `burialdate` varchar(50) NOT NULL default '',   `burialdatetr` date NOT NULL default '0000-00-00',   `burialplace` text NOT NULL,   `baptdate` varchar(50) NOT NULL default '',   `baptdatetr` date NOT NULL default '0000-00-00',   `baptplace` text NOT NULL,   `endldate` varchar(50) NOT NULL default '',   `endldatetr` date NOT NULL default '0000-00-00',   `endlplace` text NOT NULL,   `changedate` datetime default NULL,   `nickname` text NOT NULL,   `title` tinytext NOT NULL,   `suffix` tinytext NOT NULL,   `nameorder` tinyint(4) NOT NULL default '0',   `famc` varchar(22) default NULL,   `metaphone` varchar(15) NOT NULL default '',   `living` tinyint(4) NOT NULL default '0',   `branch` varchar(100) NOT NULL default '',   `changedby` varchar(20) NOT NULL default '',   PRIMARY KEY  (`ID`),   UNIQUE KEY `gedpers` (`gedcom`,`personID`),   KEY `lastname` (`lastname`,`firstname`),   KEY `gedlast` (`gedcom`,`lastname`,`firstname`),   KEY `gedfirst` (`gedcom`,`firstname`),   KEY `firstname` (`firstname`),   KEY `changedate` (`changedate`),   KEY `local_altbirthdatetr` (`altbirthdatetr`),   KEY `local_birthdatetr` (`birthdatetr`),   KEY `local_burialdatetr` (`burialdatetr`),   KEY `local_deathdatetr` (`deathdatetr`),   KEY `local_personID` (`personID`),   KEY `local_living` (`living`),   KEY `local_branch` (`branch`),   KEY `local_birthplace` (`birthplace`(255)),   KEY `local_altbirthplace` (`altbirthplace`(255)),   KEY `local_deathplace` (`deathplace`(255)),   KEY `local_burialplace` (`burialplace`(255)),   KEY `local_sex` (`sex`(1)) ) TYPE=MyISAM; CREATE TABLE `tng_families` (   `ID` int(11) NOT NULL auto_increment,   `gedcom` varchar(20) NOT NULL default '',   `familyID` varchar(22) NOT NULL default '',   `husband` varchar(22) NOT NULL default '',   `wife` varchar(22) NOT NULL default '',   `marrdate` varchar(50) NOT NULL default '',   `marrdatetr` date NOT NULL default '0000-00-00',   `marrplace` text NOT NULL,   `marrtype` varchar(50) NOT NULL default '',   `divdate` varchar(50) NOT NULL default '',   `divdatetr` date NOT NULL default '0000-00-00',   `divplace` text NOT NULL,   `status` varchar(20) NOT NULL default '',   `sealdate` varchar(50) NOT NULL default '',   `sealdatetr` date NOT NULL default '0000-00-00',   `sealplace` text NOT NULL,   `husborder` tinyint(4) NOT NULL default '0',   `wifeorder` tinyint(4) NOT NULL default '0',   `changedate` datetime default NULL,   `living` tinyint(4) NOT NULL default '0',   `branch` varchar(100) NOT NULL default '',   `changedby` varchar(20) NOT NULL default '',   PRIMARY KEY  (`ID`),   UNIQUE KEY `familyID` (`gedcom`,`familyID`),   KEY `wife` (`gedcom`,`wife`),   KEY `changedate` (`changedate`),   KEY `husband` (`gedcom`,`husband`),   KEY `local_living` (`living`),   KEY `local_marrdatetr` (`marrdatetr`),   KEY `local_wife` (`wife`),   KEY `local_husband` (`husband`),   KEY `local_marrplace` (`marrplace`(255)) ) TYPE=MyISAM; Die Tabelle tng_families ist über die Felder "husband" und "wife" mit dem Feld "personID" von tng_people verknüpft.  CREATE TABLE `tng_events` (   `eventID` int(11) NOT NULL auto_increment,   `gedcom` varchar(20) NOT NULL default '',   `persfamID` varchar(22) NOT NULL default '',   `eventtypeID` int(11) NOT NULL default '0',   `eventdate` varchar(50) NOT NULL default '',   `eventdatetr` date NOT NULL default '0000-00-00',   `eventplace` text NOT NULL,   `age` varchar(12) NOT NULL default '',   `agency` varchar(120) NOT NULL default '',   `cause` varchar(90) NOT NULL default '',   `addressID` varchar(10) NOT NULL default '',   `parenttag` varchar(10) NOT NULL default '',   `info` text NOT NULL,   PRIMARY KEY  (`eventID`),   KEY `persfamID` (`gedcom`,`persfamID`),   KEY `local_eventtypeID` (`eventtypeID`),   KEY `local_eventdatetr` (`eventdatetr`),   KEY `local_addressID` (`addressID`),   KEY `local_parenttag` (`parenttag`),   KEY `local_eventplace` (`eventplace`(255)) ) TYPE=MyISAM; Events sind so etwas wie flexible Zusatzdaten, die man zu einer Person (oder Familie) in beliebiger Art und Menge hinzufügen kann. D.h. einem Datensatz aus tng_peoples können keine, eine oder mehrere DS aus tng_events zugeordnet sein. Ein Datensatz aus der Tabelle tng_events ist über das Feld persfamID mit dem Feld personID aus tng_people verknüpft. CREATE TABLE `tng_eventtypes` (   `eventtypeID` int(11) NOT NULL auto_increment,   `tag` varchar(10) NOT NULL default '',   `description` varchar(90) NOT NULL default '',   `display` text NOT NULL,   `keep` tinyint(4) NOT NULL default '0',   `ordernum` smallint(6) NOT NULL default '0',   `type` char(1) NOT NULL default '',   PRIMARY KEY  (`eventtypeID`),   UNIQUE KEY `typetagdesc` (`type`,`tag`,`description`),   KEY `ordernum` (`ordernum`),   KEY `local_tag` (`tag`),   KEY `local_tag_descr` (`tag`,`description`) ) TYPE=MyISAM; Die Tabelle tng_eventtypes ist über das Feld "tag" mit dem Feld "eventtypeID" aus der Tabelle tng_events verknüpft. Das Feld "gedcom" in den Tabellen ist sowas wie ein Mandant - vgl. die UNIQUE KEYs. _______________________________________________ Allgemeine Infos zur Liste: http://www.4t2.com/mysql/ Verwaltung: https://lists.4t2.com/cgi-bin/mailman/listinfo/mysql-de From a.balke at digiden.de Wed May 23 00:41:23 2007 From: a.balke at digiden.de (andreas balke) Date: Wed, 23 May 2007 00:41:23 +0200 Subject: verwickelte SQL-Abfrage mit JOIN's In-Reply-To: <200705222354.30308.u.kretschmer.mysql.4t2@bergruf.de> References: <4652B97E.7020603@digiden.de> <200705222354.30308.u.kretschmer.mysql.4t2@bergruf.de> Message-ID: <46537193.2060906@digiden.de> hey ulrich, ich habe jetzt keine lust mehr die daten einzuspielen, aber das hier ist definitiv schonmal falsch, weil das ein inner join sein sollte: LEFT JOIN tng_eventtypes AS et2 ON (e2.eventtypeID=et2.eventtypeID AND ((et2.tag IS NOT NULL AND et2.description<>"Ehename") AND !(et2.tag="EVEN" andi -- Andreas Balke // Lead Developer Digiden GmbH ? Agentur für Kommunikationslösungen In der Backfabrik ? Saarbrückerstraße 37b ? D-10405 Berlin Fon: +49 (30) 446 749 425 ? Fax: +49 (30) 446 749 479 www.digiden.de -------------- nächster Teil -------------- Ein Dateianhang mit Binärdaten wurde abgetrennt... Dateiname : smime.p7s Dateityp : application/x-pkcs7-signature Dateigröße : 3236 bytes Beschreibung: S/MIME Cryptographic Signature URL : http://lists.mushaake.org/pipermail/mysql-de/attachments/20070523/b407802a/attachment.bin -------------- nächster Teil -------------- _______________________________________________ Allgemeine Infos zur Liste: http://www.4t2.com/mysql/ Verwaltung: https://lists.4t2.com/cgi-bin/mailman/listinfo/mysql-de From lists at sebastianmendel.de Wed May 23 07:53:05 2007 From: lists at sebastianmendel.de (Sebastian Mendel) Date: Wed, 23 May 2007 07:53:05 +0200 Subject: verwickelte SQL-Abfrage mit JOIN's In-Reply-To: <200705230009.24221.u.kretschmer.mysql.4t2@bergruf.de> References: <200705212103.12828.u.kretschmer.mysql.4t2@bergruf.de> <46528F8B.3060102@netbreaker.de> <465295F4.50903@sebastianmendel.de> <200705230009.24221.u.kretschmer.mysql.4t2@bergruf.de> Message-ID: <4653D6C1.30103@sebastianmendel.de> Ulrich Kretschmer schrieb: > Hallo zusammen, > > Am Dienstag 22. Mai 2007 09:04 schrieb Sebastian Mendel: >> LEFT JOIN >> tng_eventtypes AS et >> ON e.eventtypeID = et.eventtypeID >> AND et.tag = 'EVEN' >> AND et.description = 'Ehename'; >> >> (alle ohne einen event Ehename haben jetzt NULL in den et-Feldern) > > Beispielausgabe bis hierher: > http://www.ahnendaten.de/ahnen/showreport.php?reportID=226 > >> nein nein, du willst alle außer die mit dem event Ehename >> >> also, verknüpfts die deine Personen NUR mit genau diesem >> Ausschlusskriterium und filterst alle ungleich NULL aus (HAVING >> IS_NULL(et.tag)) > > Beispielausgabe hierzu: > http://www.ahnendaten.de/ahnen/showreport.php?reportID=227 > > D.h. damit verschwinden gegenüber dem ersten Beispiel zwar die Zeilen mit > "Ehename", aber das ist es auch noch nicht ganz. Denn es sollen alle Zeilen > zu denjenigen Personen, die bereits einen Ehenamen zugeordnet haben, nicht > mehr erscheinen. naja, ein bissl Eigenleistung ... ;-) du musst die obige methodik natürlich an der Tabelle `tng_events` ansetzen, da diese ja natürlich die eigentliche Tabelle mit den Infos zu den EVENT und Ehename ist ... LEFT JOIN tng_events AS e ON w.personID = e.persfamID AND w.gedcom = e.gedcom AND e.eventtypeID = [id_für_event_Ehename] -- Sebastian Mendel www.sebastianmendel.de _______________________________________________ Allgemeine Infos zur Liste: http://www.4t2.com/mysql/ Verwaltung: https://lists.4t2.com/cgi-bin/mailman/listinfo/mysql-de From benedikt at quirmbach.de Fri May 25 10:55:25 2007 From: benedikt at quirmbach.de (Benedikt Quirmbach) Date: Fri, 25 May 2007 10:55:25 +0200 Subject: nur ein Eintrag Message-ID: <1132D927-0A97-4330-BBEF-87282CDAF0BA@quirmbach.de> Hallo, ich habe eine Tabelle mit einigen Datensätzen. Diese Datensätze sind verschiedenen "Besitzern" zugeordnet. Die "Besitzer" werden mit einer ID-Nummer unterschieden (Feldbezeichnung: "besitzer"). Ich brauche jetzt eine Abfrage, die mir die ID-Nummern der Besitzer liefert, die nur einen einzigen Datensatz in der Tabelle haben. Also alle Besitzernummern, die nur einmal vorkommen. Wie geht das? Viele Grüße Benedikt _______________________________________________ Allgemeine Infos zur Liste: http://www.4t2.com/mysql/ Verwaltung: https://lists.4t2.com/cgi-bin/mailman/listinfo/mysql-de From lists at sebastianmendel.de Fri May 25 11:06:59 2007 From: lists at sebastianmendel.de (Sebastian Mendel) Date: Fri, 25 May 2007 11:06:59 +0200 Subject: nur ein Eintrag In-Reply-To: <1132D927-0A97-4330-BBEF-87282CDAF0BA@quirmbach.de> References: <1132D927-0A97-4330-BBEF-87282CDAF0BA@quirmbach.de> Message-ID: <4656A733.5040804@sebastianmendel.de> Benedikt Quirmbach schrieb: > Hallo, > > ich habe eine Tabelle mit einigen Datensätzen. > Diese Datensätze sind verschiedenen "Besitzern" zugeordnet. > Die "Besitzer" werden mit einer ID-Nummer unterschieden > (Feldbezeichnung: "besitzer"). > > Ich brauche jetzt eine Abfrage, die mir die ID-Nummern der Besitzer > liefert, die nur einen einzigen Datensatz in der Tabelle haben. > Also alle Besitzernummern, die nur einmal vorkommen. > > Wie geht das? Wie hast du es denn bisher probiert? COUNT() ... GROUP BY ... HAVING -- Sebastian Mendel www.sebastianmendel.de _______________________________________________ Allgemeine Infos zur Liste: http://www.4t2.com/mysql/ Verwaltung: https://lists.4t2.com/cgi-bin/mailman/listinfo/mysql-de From benedikt at quirmbach.de Fri May 25 12:15:26 2007 From: benedikt at quirmbach.de (Benedikt Quirmbach) Date: Fri, 25 May 2007 12:15:26 +0200 Subject: nur ein Eintrag In-Reply-To: <4656A733.5040804@sebastianmendel.de> References: <1132D927-0A97-4330-BBEF-87282CDAF0BA@quirmbach.de> <4656A733.5040804@sebastianmendel.de> Message-ID: Hallo, danke für die Antwort. Ich habe noch gar nichts probiert, weil ich gar nicht weiß, nach welchen Stichworten ich suchen sollte. Vielleicht komme ich ja mit Deiner Frage weiter. Das einzige, was mir bis jetzt eingefallen ist, ist per PHP durch meine Datenbank zu rauschen und die entsprechenden Nummern in ein Array zu schreiben. Aber erstens ist das für den gewünschten Zweck etwas aufwändig und zweitens muss es ja auch irgendwie per SQL gehen... Wenn man denn SQL könnte... Benedikt Am 25.05.2007 um 11:06 schrieb Sebastian Mendel: > Benedikt Quirmbach schrieb: >> Hallo, >> >> ich habe eine Tabelle mit einigen Datensätzen. >> Diese Datensätze sind verschiedenen "Besitzern" zugeordnet. >> Die "Besitzer" werden mit einer ID-Nummer unterschieden >> (Feldbezeichnung: "besitzer"). >> >> Ich brauche jetzt eine Abfrage, die mir die ID-Nummern der Besitzer >> liefert, die nur einen einzigen Datensatz in der Tabelle haben. >> Also alle Besitzernummern, die nur einmal vorkommen. >> >> Wie geht das? > > Wie hast du es denn bisher probiert? > > COUNT() ... GROUP BY ... HAVING > > > -- > Sebastian Mendel > > www.sebastianmendel.de > _______________________________________________ > Allgemeine Infos zur Liste: http://www.4t2.com/mysql/ > Verwaltung: https://lists.4t2.com/cgi-bin/mailman/listinfo/mysql-de _______________________________________________ Allgemeine Infos zur Liste: http://www.4t2.com/mysql/ Verwaltung: https://lists.4t2.com/cgi-bin/mailman/listinfo/mysql-de From lists at sebastianmendel.de Fri May 25 12:25:52 2007 From: lists at sebastianmendel.de (Sebastian Mendel) Date: Fri, 25 May 2007 12:25:52 +0200 Subject: nur ein Eintrag In-Reply-To: References: <1132D927-0A97-4330-BBEF-87282CDAF0BA@quirmbach.de> <4656A733.5040804@sebastianmendel.de> Message-ID: <4656B9B0.9000504@sebastianmendel.de> Benedikt Quirmbach schrieb: > Hallo, > > danke für die Antwort. > > Ich habe noch gar nichts probiert, weil ich gar nicht weiß, nach > welchen Stichworten ich suchen sollte. > Vielleicht komme ich ja mit Deiner Frage weiter. > > Das einzige, was mir bis jetzt eingefallen ist, ist per PHP durch > meine Datenbank zu rauschen und die entsprechenden Nummern in ein > Array zu schreiben. Aber erstens ist das für den gewünschten Zweck > etwas aufwändig und zweitens muss es ja auch irgendwie per SQL > gehen... Wenn man denn SQL könnte... naja dann, wie geschrieben, deine Freunde sind: COUNT() ... GROUP BY ... HAVING SELECT `fk_besitzer`, COUNT(`pk`) AS `count` FROM `table` GROUP BY `fk_besitzer` HAVING `count` = 1 -- Sebastian Mendel www.sebastianmendel.de _______________________________________________ Allgemeine Infos zur Liste: http://www.4t2.com/mysql/ Verwaltung: https://lists.4t2.com/cgi-bin/mailman/listinfo/mysql-de From info at helgeraab.de Fri May 25 12:24:57 2007 From: info at helgeraab.de (Helge Raab) Date: Fri, 25 May 2007 12:24:57 +0200 Subject: nur ein Eintrag In-Reply-To: <1132D927-0A97-4330-BBEF-87282CDAF0BA@quirmbach.de> References: <1132D927-0A97-4330-BBEF-87282CDAF0BA@quirmbach.de> Message-ID: <4656B979.8070808@helgeraab.de> Hallo, versuchs mit select besitzer, count(besitzer) from tabelle ??? group by besitzer having count(besitzer)=1; Funktioniert's? Viele Grüße Helge Benedikt Quirmbach schrieb: > Hallo, > > ich habe eine Tabelle mit einigen Datensätzen. > Diese Datensätze sind verschiedenen "Besitzern" zugeordnet. > Die "Besitzer" werden mit einer ID-Nummer unterschieden > (Feldbezeichnung: "besitzer"). > > Ich brauche jetzt eine Abfrage, die mir die ID-Nummern der Besitzer > liefert, die nur einen einzigen Datensatz in der Tabelle haben. > Also alle Besitzernummern, die nur einmal vorkommen. > > Wie geht das? > > Viele Grüße > Benedikt > _______________________________________________ > Allgemeine Infos zur Liste: http://www.4t2.com/mysql/ > Verwaltung: https://lists.4t2.com/cgi-bin/mailman/listinfo/mysql-de > > -- Helge Raab Training & Beratung Akazienstr. 5 * 81547 München Tel 089/18934756 * Fax 089/18934757 XING: http://www.xing.com/profile/Helge_Raab www.helgeraab.de _______________________________________________ Allgemeine Infos zur Liste: http://www.4t2.com/mysql/ Verwaltung: https://lists.4t2.com/cgi-bin/mailman/listinfo/mysql-de From benedikt at quirmbach.de Fri May 25 13:16:53 2007 From: benedikt at quirmbach.de (Benedikt Quirmbach) Date: Fri, 25 May 2007 13:16:53 +0200 Subject: nur ein Eintrag In-Reply-To: <4656B979.8070808@helgeraab.de> References: <1132D927-0A97-4330-BBEF-87282CDAF0BA@quirmbach.de> <4656B979.8070808@helgeraab.de> Message-ID: <375239A1-0209-4BD1-98CD-6A5F6F361118@quirmbach.de> Hallo Helge, ja, das funktioniert ganz prima! Vielen Dank Benedikt Am 25.05.2007 um 12:24 schrieb Helge Raab: > Hallo, > > versuchs mit > > select besitzer, count(besitzer) from tabelle ??? group by besitzer > having count(besitzer)=1; > > Funktioniert's? > > Viele Grüße > Helge > > > Benedikt Quirmbach schrieb: >> Hallo, >> >> ich habe eine Tabelle mit einigen Datensätzen. >> Diese Datensätze sind verschiedenen "Besitzern" zugeordnet. >> Die "Besitzer" werden mit einer ID-Nummer unterschieden >> (Feldbezeichnung: "besitzer"). >> >> Ich brauche jetzt eine Abfrage, die mir die ID-Nummern der Besitzer >> liefert, die nur einen einzigen Datensatz in der Tabelle haben. >> Also alle Besitzernummern, die nur einmal vorkommen. >> >> Wie geht das? >> >> Viele Grüße >> Benedikt >> _______________________________________________ >> Allgemeine Infos zur Liste: http://www.4t2.com/mysql/ >> Verwaltung: https://lists.4t2.com/cgi-bin/mailman/listinfo/mysql-de >> >> > > -- > Helge Raab Training & Beratung > Akazienstr. 5 * 81547 München > Tel 089/18934756 * Fax 089/18934757 > XING: http://www.xing.com/profile/Helge_Raab > www.helgeraab.de > > _______________________________________________ > Allgemeine Infos zur Liste: http://www.4t2.com/mysql/ > Verwaltung: https://lists.4t2.com/cgi-bin/mailman/listinfo/mysql-de _______________________________________________ Allgemeine Infos zur Liste: http://www.4t2.com/mysql/ Verwaltung: https://lists.4t2.com/cgi-bin/mailman/listinfo/mysql-de