Zwei Reihen mit UND verknüpfen

[Harry]

Holladiewaldfee,

zur Abwechslung mal eine Datenbankfrage.
Ich habe eine Tabelle (echt!):

vid      tid     wert
----------------------
1        1       a
1        2       b
2        1       a
2        2       c

Nun muß ich eine Query derart formulieren, daß ich die VIDs
zurückbekomme, für die gilt:

bei tid=1 steht wert='a'
und darüberhinaus bei tid=2 wert='b',

also in diesem Fall 1.
Mit "oder" verknüpft ist die Sache ja relativ problemlos (einfach
mit DISTINCT düber und alles doppelte ist weg), mit "und" gibt's
aber Ärger, weil natürlich

(tid=1 AND wert='a') AND (tid=2 AND wert='b')

wie erwartet nichts zurückliefert (klar ... tid=1 und tid=2
gleichzeitig ist Ramsch).

Prinzipiell muß ich also Bedingungen an mehrere Reihen stellen, die
dieselbe VID haben. Gibt's sowas wie

SELECT DISTINCT vid FROM misttabelle WHERE (tid=1 AND wert='a' AND
vid=$variable) AND WOANDERS (tid=2 AND wert='b' AND vid=$variable);?

Ich habe leider so das dumpfe Gefühl, daß das überhaupt nicht
funktioniert ... Wäre nett, wenn mir jemand da was genaueres sagen
könnte. Danke.

Ciao,

Harry

[Cheatah]

Hi,

Ich habe eine Tabelle (echt!):

boah :-)

Ich habe leider so das dumpfe Gefühl, daß das überhaupt nicht
funktioniert ... Wäre nett, wenn mir jemand da was genaueres sagen
könnte. Danke.

Lange Rede, kurzes Stichwort: Self-Join.

Cheatah

[Harry]

Holladiewaldfee,

Lange Rede, kurzes Stichwort: Self-Join.

Danke. Da wäre ich von selber wohl nie drauf gekommen (oder zumindest nicht mehr heute).

Jetzt bleibt die Frage, wie weit kann ich das mit dem self-join treiben? Das Beispiel war stark vereinfacht, ich muß eigentlich eine relativ hohe Anzahl an Bedingungen an mehere Zeilen stellen.

Ich meine, ich könnte jetzt die Tabelle ~50 mal mit sich selbst verknüpfen ... das ist aber a) eklig und b) macht wahrscheinlich der Datenbankserver 'nen Abgang. Soweit ich weiß soll man ja JOINs wenn möglich vermeiden ... und dann gleicht 50 Stück auf einmal, in einer Query?!

Ciao,

Harry

[Cheatah]

Hi,

Jetzt bleibt die Frage, wie weit kann ich das mit dem self-join treiben?

solange, bis Dir nette Menschen ein hübsches weißes Jäckchen verpassen und Dich in einen angenehm gepolsterten Raum verfrachten, während Du mit rollenden Augen "Self-Join! Self-Join! Muhuhuahaha!!!" schreist.

Ich meine, ich könnte jetzt die Tabelle ~50 mal mit sich selbst verknüpfen ... das ist aber a) eklig und b) macht wahrscheinlich der Datenbankserver 'nen Abgang.

Wenn das DBMS dabei in die Knie geht, hast Du das falsche eingesetzt. Vorausgesetzt natürlich, Dein DB-Layout ist vernünftig :-)

Soweit ich weiß soll man ja JOINs wenn möglich vermeiden ...

Diese Behauptung widerspricht eklatant dem Modell einer relationalen Datenbank.

und dann gleicht 50 Stück auf einmal, in einer Query?!

Ein solches Statement ist zumindest nicht mehr vernünftig wartbar, das ist klar. Bei einer derartigen Masse an Bedingungen möchtest Du vermutlich entweder Dein DB-Layout noch mal überdenken, oder Teile des Selects in umgebende Programmlogik auslagern, oder beides.

Cheatah

[Alexander Foken]

Moin Moin !

Jetzt bleibt die Frage, wie weit kann ich das mit dem self-join treiben?

solange, bis Dir nette Menschen ein hübsches weißes Jäckchen verpassen und Dich in einen angenehm gepolsterten Raum verfrachten, während Du mit rollenden Augen "Self-Join! Self-Join! Muhuhuahaha!!!" schreist.

Das sind doch die Standard-Symtome nach einem Grundkurs MSSQL-Server, oder?

Ich meine, ich könnte jetzt die Tabelle ~50 mal mit sich selbst verknüpfen ... das ist aber a) eklig und b) macht wahrscheinlich der Datenbankserver 'nen Abgang.

Wenn das DBMS dabei in die Knie geht, hast Du das falsche eingesetzt. Vorausgesetzt natürlich, Dein DB-Layout ist vernünftig :-)

Naja, im Zweifel legt man halt noch einen Index über die betroffenen Spalten nach.

EXPLAIN soll gerüchteweise auch helfen. ;-)

Soweit ich weiß soll man ja JOINs wenn möglich vermeiden ...

Diese Behauptung widerspricht eklatant dem Modell einer relationalen Datenbank.

und dann gleicht 50 Stück auf einmal, in einer Query?!

Ein solches Statement ist zumindest nicht mehr vernünftig wartbar, das ist klar. Bei einer derartigen Masse an Bedingungen möchtest Du vermutlich entweder Dein DB-Layout noch mal überdenken, oder Teile des Selects in umgebende Programmlogik auslagern, oder beides.

Sehe ich auch so. So viele Bedingungen zeigen normalerweise an, daß da irgendwelche Abhängigkeiten drin sind, die durch Normalisieren der Datenbank (Stichwort "3. Normalform") rauszufummeln sind.

Zu viele Daten in eine Tabelle gequetscht?

Alexander

[Harry]

Holladiewaldfee,

(Stichwort "3. Normalform")

Äh ... ja.
Hast Du 'nen Link dazu? Kann man die essen?

Zu viele Daten in eine Tabelle gequetscht?

Meiner Meinung nach nicht.
Bloß zu viele variable Bedingungen ...

Ciao,

Harry

[Alexander Foken]

Moin Moin !

Holladiewaldfee,

(Stichwort "3. Normalform")

Äh ... ja.
Hast Du 'nen Link dazu? Kann man die essen?

1. http://www.google.com/search?q=dritte+normalform+datenbank (hättest Du Dir denken können, oder?)
2. Aus "Russisch Brot" schon.

Zu viele Daten in eine Tabelle gequetscht?

Meiner Meinung nach nicht.
Bloß zu viele variable Bedingungen ...

Divide et impera - oder so. Teile und herrsche.

Meine Adressverwaltung in meinem Projekt sieht im Prinzip so aus:

BENUTZER -> KONTAKTDATEN
             mail
             anrede
             id_lieferadresse
             id_büroadresse
             id_privatadresse
             id_sonstigeadresse

Die vier IDs verweisen auf eine gemeinsame Adressentabelle.

Mittlerweile würde ich die vier IDs auslagern und eine weitere Tabelle zwischen KONTAKTDATEN und die Adressentabelle setzen, die beliebig viele Adressen zu einem Benutzer erlaubt.

Alexander

[Cheatah]

Hi,

solange, bis Dir nette Menschen ein hübsches weißes Jäckchen verpassen und Dich in einen angenehm gepolsterten Raum verfrachten, während Du mit rollenden Augen "Self-Join! Self-Join! Muhuhuahaha!!!" schreist.
Das sind doch die Standard-Symtome nach einem Grundkurs MSSQL-Server, oder?

nur, wenn sich die Patien^WTeilnehmer schon mit _richtigen_ Datenbanken auskannten.

Wenn das DBMS dabei in die Knie geht, hast Du das falsche eingesetzt. Vorausgesetzt natürlich, Dein DB-Layout ist vernünftig :-)
Naja, im Zweifel legt man halt noch einen Index über die betroffenen Spalten nach.

Ungefähr das wollte ich damit sagen.

EXPLAIN soll gerüchteweise auch helfen. ;-)

Da das Statement generiert wird: Unbedingt auf alle Details achten ... :-)

Sehe ich auch so. So viele Bedingungen zeigen normalerweise an, daß da irgendwelche Abhängigkeiten drin sind, die durch Normalisieren der Datenbank (Stichwort "3. Normalform") rauszufummeln sind.

Japp, genau.

Cheatah

[Harry]

Holladiewaldfee,

solange, bis Dir nette Menschen ein hübsches weißes Jäckchen verpassen und Dich in einen angenehm gepolsterten Raum verfrachten, während Du mit rollenden Augen "Self-Join! Self-Join! Muhuhuahaha!!!" schreist.

*augenroll* Muhuhuaauauauaa Self-Join, Self-Join dididdldldld
tüüüüüüüüüüü
gagaga nagn nagn
hehehehehehe sel sel seeeeeelfffjoooooiiiinnnn
*bonk*
*bonk*
säääääääälllllllflfffflflffl joiiihiiihihihihihihihi
*bonk*
Muiahaaahahaha sädl dädl döö
*gnargh*

Wenn das DBMS dabei in die Knie geht, hast Du das falsche eingesetzt. Vorausgesetzt natürlich, Dein DB-Layout ist vernünftig :-)

Na dann werd ich's mal probieren ... das wird _die_ Monsterquery ;-) Ich glaube ich muß dann hier unbedingt mal eine als Beispiel posten *g*
Ach ja, als Datenbank setze ich (oh Wunder) MySQL ein.

Ein solches Statement ist zumindest nicht mehr vernünftig wartbar, das ist klar.

Das Statement soll keiner warten, das Statement wird komplett von einem PHP-Script erzeugt.

Hintergrund ist folgender:
Ich habe eine Adressdatenbank mit einer variablen Anzahl an Spalten. Um diesem Umstand Rechnung zu tragen werde die Daten eben in der erwähnten Tabelle mit den Spalten vid, tid und wert gepspeichert. tid spezifiziert dabei die Eigenschaft, vid die Nummer des Eintrages und wert *trommelwirbel* den Wert.

Bei einer derartigen Masse an Bedingungen möchtest Du vermutlich entweder Dein DB-Layout noch mal überdenken, oder Teile des Selects in umgebende Programmlogik auslagern, oder beides.

Ich habe auch schon daran gedacht, das Select teilweise auszulagern ... das Problem ist jedoch, daß ich nur eingeschränkt eine Vorauswahl treffen kann, ohne mit Self-Joins zu arbeiten. Und dann müsste ich aufeinmal mit riesigen Datenmengen im PHP-Script hantieren, was ich eigentlich vermeiden will.

Das DB-Layout hat einer entworfen, der's eigentlich können sollte (also nicht ich *g*). Außerdem müsste ich dann jedesmal, wenn ich eine neue Spalte hinzufüge / lösche mit 'nem ALTER TABLE an die Tabelle hin ...

Ciao,

Muaahahahahaharry

[Alexander Foken]

Moin Moin !

solange, bis Dir nette Menschen ein hübsches weißes Jäckchen verpassen und Dich in einen angenehm gepolsterten Raum verfrachten, während Du mit rollenden Augen "Self-Join! Self-Join! Muhuhuahaha!!!" schreist.

*augenroll* Muhuhuaauauauaa Self-Join, Self-Join dididdldldld
tüüüüüüüüüüü
gagaga nagn nagn
hehehehehehe sel sel seeeeeelfffjoooooiiiinnnn
*bonk*
*bonk*
säääääääälllllllflfffflflffl joiiihiiihihihihihihihi
*bonk*
Muiahaaahahaha sädl dädl döö
*gnargh*

Hmm, Du hast den Level der ersten Kaffeepause im MSSQL-Grundkurs erreicht. Nur weiter so.

SCNR!

Hintergrund ist folgender:
Ich habe eine Adressdatenbank mit einer variablen Anzahl an Spalten. Um diesem Umstand Rechnung zu tragen werde die Daten eben in der erwähnten Tabelle mit den Spalten vid, tid und wert gepspeichert. tid spezifiziert dabei die Eigenschaft, vid die Nummer des Eintrages und wert *trommelwirbel* den Wert.

Aaarg! Das ist nun wirklich Krampf.

Das DB-Layout hat einer entworfen, der's eigentlich können sollte (also nicht ich *g*). Außerdem müsste ich dann jedesmal, wenn ich eine neue Spalte hinzufüge / lösche mit 'nem ALTER TABLE an die Tabelle hin ...

Wie oft kommt das vor? Die Struktur einer Adressdatenbank sollte sich ja nun nicht gerade alle fünf Minuten ändern.

Außerdem solltest Du auch in MySQL an die Metadaten der Tabelle rankommen, sprich: Mit irgendeinem SELECT-Statement (oder einer MySQL-spezifischen Variante) solltest Du herausfinden können, welche Spalten Deine Tabelle hat, welche Typen und "Extras" (NOT NULL, PRIMARY KEY, INDEX, ...) sie haben. Wenn nicht, kannst Du diese Informationen in einer zweiten Tabelle halten.

Ich arbeite beruflich seit über drei Jahren an einem Programm, dessen Stärke variable Tabellen sind. Vier der Haupttabellen haben eine kundenspezifische Struktur, an die sich das Programm automatisch anpaßt, dank einer eigenen Hilfstabelle, in der alle Tabellen mit Spalten, (eigenen) Datentypen und Extras aufgeführt sind. ALTER TABLE macht das Programm notfalls selbst. Gelöscht werden überflüssige Spalten übrigens nicht, sie bleiben einfach ungenutzt stehen, werden aber nicht angezeigt.

Alexander

[Harry]

Holladiewaldfee,

Wie oft kommt das vor? Die Struktur einer Adressdatenbank sollte sich ja nun nicht gerade alle fünf Minuten ändern.

HMPF ... meine Rede.
Nein, es darf kein ALTER TABLE sein, da hab ich (leider) nix mitzureden.

Außerdem solltest Du auch in MySQL an die Metadaten der Tabelle rankommen, sprich: Mit irgendeinem SELECT-Statement (oder einer MySQL-spezifischen Variante) solltest Du herausfinden können, welche Spalten Deine Tabelle hat, welche Typen und "Extras" (NOT NULL, PRIMARY KEY, INDEX, ...) sie haben. Wenn nicht, kannst Du diese Informationen in einer zweiten Tabelle halten.

Alles kein Problem ...
Aber wie gesagt: Ich hätte es anders gelöst (lieber mit ALTER TABLE), aber ich hatte bei der Datenbankstruktur nicht wirklich viel mitzureden.

Danke Dir für Deine Hilfe.

Ciao,

Harry

[Michael Schröpl]

Hi Harry,

Das DB-Layout hat einer entworfen, der's eigentlich können sollte (also nicht ich *g*). Außerdem müsste ich dann jedesmal, wenn ich eine neue Spalte hinzufüge / lösche mit 'nem ALTER TABLE an die Tabelle hin ...

richtig. Und gleichzeitig die SQL-Query-Logik sämtlicher existierender Applikationen überprüfen und ggf. anpassen.
Ersteres 'erspart' Dir Dein Datenmodell, letzteres nicht. Was von beiden im aber schlimmer?

Viele Grüße
      Michael

[Harry]

Holladiewaldfee,

Na dann werd ich's mal probieren ... das wird _die_ Monsterquery ;-) Ich glaube ich muß dann hier unbedingt mal eine als Beispiel posten *g*

Muahahahahahahahahahhahaahah
*gnargh* ...
So, ich hatte ja angedroht mal 'ne Beispielquery zu posten, die mein Script generiert hat *g*

SELECT DISTINCT d.vid, u.permission AS uperm, rights.permission AS gperm FROM data AS d, permission_user AS u, permission_group AS rights, data AS d0, data AS d1, data AS d2, data AS d3, data AS d4, data AS d5, data AS d6, data AS d7, data AS d8, data AS d9, data AS d10, data AS d11, data AS d12, data AS d13, data AS d14, data AS d15, data AS d16 WHERE ( (d.tid=2 OR d.tid=3 OR d.tid=1 OR d.tid=4 OR d.tid=6 OR d.tid=7 OR d.tid=8 OR d.tid=9 OR d.tid=10 OR d.tid=11 OR d.tid=12 OR d.tid=13 OR d.tid=14 OR d.tid=18 OR d.tid=15 OR d.tid=16 OR d.tid=17 OR d.tid=19 OR d.tid=20 OR d.tid=21 OR d.tid=22 OR d.tid=23 OR d.tid=24 OR d.tid=25 OR d.tid=26 OR d.tid=27 OR d.tid=28 OR d.tid=29 OR d.tid=30 OR d.tid=31 OR d.tid=32 OR d.tid=33) AND ( ( (rights.gid=1 OR rights.gid=2 OR rights.gid=3 OR rights.gid=4) AND rights.vid=d.vid ) OR ( u.uid=0 AND u.vid=d.vid ) ) ) AND (d.vid = d0.vid AND d.vid = d1.vid AND d.vid = d2.vid AND d.vid = d3.vid AND d.vid = d4.vid AND d.vid = d5.vid AND d.vid = d6.vid AND d.vid = d7.vid AND d.vid = d8.vid AND d.vid = d9.vid AND d.vid = d10.vid AND d.vid = d11.vid AND d.vid = d12.vid AND d.vid = d13.vid AND d.vid = d14.vid AND d.vid = d15.vid AND d.vid = d16.vid) AND (((INSTR(d0.value, 'brei')>0) AND d0.tid=2) AND ((INSTR(d1.value, 'ra')>0) AND d1.tid=1) AND ((INSTR(d2.value, 'ons')>0) AND d2.tid=4) AND ((INSTR(d3.value, 'otk')>0) AND d3.tid=9) AND ((INSTR(d4.value, 'rets')>0 OR INSTR(d4.value, 'ried')>0) AND d4.tid=11) AND ((INSTR(d5.value, '8171')>0 OR INSTR(d5.value, '90')>0 OR INSTR(d5.value, '27')>0) AND d5.tid=16) AND ((INSTR(d6.value, 'rry')>0) AND d6.tid=22) AND (d7.value=82538 AND d7.tid=10) AND (d8.value=1 AND d8.tid=30) AND (d9.value=0 AND d9.tid=31) AND (d10.value=0 AND d10.tid=32) AND (d11.value=1 AND d11.tid=33) AND (((d12.value=2) AND d12.tid=7) AND ((d13.value=1) AND d13.tid=6) AND ((d14.value=1) AND d14.tid=8) AND ((d15.value=1) AND d15.tid=18) AND ((d16.value=3) AND d16.tid=25))) ORDER BY d.vid ASC

heheh ...
irgendwie gaga ...
sind jetzt zwar nur 16 self-joins, aber was solls ... ist sicher noch ausbaufähig

Muahahasfhdjashfksdgdgrdr...

- - -

Guten Tag,

Herr Breitkreutz wurde in seine Gummizelle zurückgebracht. Sie können jetzt in Ruhe weiterposten und brauchen keine Bedenken mehr zu haben.

Mit freundlichen Grüßen,

Harry's Psychiater
 (Zertifizierter MsSQL-Grundkurs-Abgänger-Behandler, auch Behandlung nach MsSQL-Professional-Super-Duper-M$-Certified-Expert-Superchecker-Hammermörderdatenbankadmin-Überflieger-Kurs möglich)

[Michael Schröpl]

Hi Harry,

d.tid=2 OR d.tid=3 OR d.tid=1 OR d.tid=4

äh, der Operator "BETWEEN" ist Dir anscheinend nicht bekannt?

Viele Grüße
      Michael

[Harry]

Holladiewaldfee,

Wahnsinn ... es gibt echt Leute, die das lesen *g*

äh, der Operator "BETWEEN" ist Dir anscheinend nicht bekannt?

doch, ist er eigentlich.
Allerdings habe ich mich bis jetzt davor gedrückt, ihn auch noch zu implementieren. Das würde die Generierung der Query nämlich stark verkomplizieren, wenn ich jedesmal die ganzen Wertebereiche prüfen müsste.

Bei dem Projekt handelt es sich um keine geschwindigkeitskritische Anwendung, deswegen habe ich mir diesen Mehraufwand gespart.

Ciao,

Harry

[Michael Schröpl]

Hi Harry,

äh, der Operator "BETWEEN" ist Dir anscheinend nicht bekannt?
doch, ist er eigentlich.
Allerdings habe ich mich bis jetzt davor gedrückt, ihn auch noch zu implementieren. Das würde die Generierung der Query nämlich stark verkomplizieren, wenn ich jedesmal die ganzen Wertebereiche prüfen müsste.

Alternative: "IN" mit Mengen-Syntax. Nicht so schön wie BETWEEN, aber leichter zu generieren.

Viele Grüße
      Michael

[Harry]

Holladiewaldfee,

Alternative: "IN" mit Mengen-Syntax. Nicht so schön wie BETWEEN, aber leichter zu generieren.

Stimmt, Danke.
An den hatte ich gar nicht mehr gedacht ...

Ciao,

Harry

[Michael Schröpl]

Hi Harry,

Ich meine, ich könnte jetzt die Tabelle ~50 mal mit sich selbst verknüpfen ...

die Anzahl der JOINs hängt nicht von der Komplexität der WHERE-Bedingungen ab, sondern von der _Anzahl_ der "WOANDERS"-Ebenen.

das ist aber a) eklig und b) macht wahrscheinlich der Datenbankserver 'nen Abgang.

50 mal eine Tabelle mit sich selbst JOINen - ja, das sollte man vermeiden (weil diese "50" dann wahrscheinlich irgendwo im Exponenten der Komplexitätsformel auftaucht).

Soweit ich weiß soll man ja JOINs wenn möglich vermeiden ...

So krass würde ich es nun auch wieder nicht formulieren wollen. Aber es sind sicherlich Fälle konstruierbar, in denen Du mit einem full table scan und einer 3GL-Logik glücklicher wirst.

Viele Grüße
      Michael

[Harry]

Holladiewaldfee,

So krass würde ich es nun auch wieder nicht formulieren wollen. Aber es sind sicherlich Fälle konstruierbar, in denen Du mit einem full table scan und einer 3GL-Logik glücklicher wirst.

3GL ... ist das ein Sportfahrwerk?

Was genau ist das? Ich kenn mich dazu leider etwas zu wenig aus ... Wenn man vollstudierter Datenbankadmin sein muß, um mit sowas zurecht zu kommen, dann is eh umsonst ;)

Danke Dir.

Ciao,

Harry

[Michael Schröpl]

Hi Harry,

3GL ... ist das ein Sportfahrwerk?

nein - ein Archiv-Suchbegriff. ;-)

Viele Grüße
      Michael

[Michael Schröpl]

Hi Harry,

SELECT DISTINCT vid FROM misttabelle WHERE (tid=1 AND wert='a' AND
vid=$variable) AND WOANDERS (tid=2 AND wert='b' AND vid=$variable);?

WOANDERS geht üblicherweise dadurch, daß Du die Tabelle mit sich selbst JOINst (über passende Bedingungen) und davon dann wiederum die benötigten Spalten herausprojezierst.

Viele Grüße
      Michael