Datensätze mehrerer Tabellen (Join, View) in eine Abfrage

[ralphi]

Hi Leute,

ich basteln mir gerade einen Timer als webside.
Dazu möchte ich unter anderem eine SQL-Abfrage für 3 Tabellen für je einen Tag in der Seite einbauen.

Bsp: für den Tag: 2013-03-01

Tabelle events:
datum , Uhrzeit, name etc.
2013-03-01, 9:00, Messe
2013-03-01, 14:00, Bürotag

Tabelle termine:
datum , Uhrzeit, name etc.
2013-03-01, 10:00, Kunde1
2013-03-01, 11:30, Kunde2

Tabelle berichte:
datum , Uhrzeit, name etc.
2013-03-01, 7:00, log1
2013-03-01, 20:00, log2

Rauskommen sollte:
Tabelle result:
datum , Uhrzeit, name etc.
2013-03-01, 7:00, log1
2013-03-01, 9:00, Messe
2013-03-01, 10:00, Kunde1
2013-03-01, 11:30, Kunde2
2013-03-01, 14:00, Bürotag
2013-03-01, 20:00, log2

Name und Uhrzeit – aus den 3 Tabellen events, berichte, termine
Mit einem SQL- Befehl abfragen und alle Datensätze nach Uhrzeit sortieren.
Zu den Spalten: datum, name, uhrzeit gibt es noch unterschiedliche weitere Spalten, je Tabelle, die aber in dieser Abfrage nicht interessieren.

Mit

SELECT * FROM (events AS EV  
INNER JOIN berichte AS BE  
ON EV.datum = BE.datum)  
INNER JOIN termine  
ON EV.datum = termine.datum  
WHERE EV.datum = '2013-03-01';

Hier liefert er mir 3x name, 3x uhrzeit als Spalten also nur einen nicht 3 Datensätze.

Mit:

CREATE VIEW TABELLE AS  
 SELECT datum, name, uhrzeit  
 FROM events  
 WHERE datum = '2013-03-01';

Hier hab ich einen View TABELLE von der tabelle ‚events’, weiß aber nicht wie ich den View mit INSERT mit dem Inhalt der anderen Tabellen erweitern kann.

INSERT INTO TABELLE (datum, name, uhrzeit) VALUES  
(SELECT datum, name,uhrzeit FROM termine)  
WHERE datum = '2013-03-01';

Klappt schon mal gar nicht.;-) Ist auch ein Schmarrn.

Wenn ich die 3 Tabellen einfach hintereinander abfrage, hab ich zwar alle Datensätze –> logisch. Aber das sortieren nach Uhrzeit über alle ist recht umständlich (nicht schön) in Array packen -> sotieren etc.

Hat jemand eine EIN Codezeilenlösung für mich?

Grüße aus LA
ralphi

[dedlfix]

Tach!

Mit

SELECT * FROM (events AS EV

INNER JOIN berichte AS BE
ON EV.datum = BE.datum)
INNER JOIN termine
ON EV.datum = termine.datum
WHERE EV.datum = '2013-03-01';

>   
> Hier liefert er mir 3x name, 3x uhrzeit als Spalten also nur einen nicht 3 Datensätze.  
  
Ja, es gibt keine Bedingung, mit der die Daten zusammengefügt werden können, also wird ein kartesisches Produkt gebildet: jeder mit jedem.  
  

> Wenn ich die 3 Tabellen einfach hintereinander abfrage, hab ich zwar alle Datensätze –> logisch. Aber das sortieren nach Uhrzeit über alle ist recht umständlich (nicht schön) in Array packen -> sotieren etc.  
  
Die einzige Möglichkeit, Daten abzufragen, die nicht miteinander verheiratet werden sollen, ist mehrere SELECTs mit UNION zu verbinden. Da kann man auch ein globales ORDER BY anhängen. Die genaue Syntax steht im Handbuch deines DBMS.  
  
  
dedlfix.

[ralphi]

Hi,

Die einzige Möglichkeit, Daten abzufragen, die nicht miteinander verheiratet werden sollen, ist mehrere SELECTs mit UNION zu verbinden. Da kann man auch ein globales ORDER BY anhängen. Die genaue Syntax steht im Handbuch deines DBMS.

habs zwar noch nicht ausprobiert,
aber nach googln scheint UNION (kannte ich vorher nicht) das richtige (einzige) dafür zu sein.

prima - danke

kann ich diese UNION - abfragen in einem View (temp-tabelle) zusammenfassen?
Bleibt eigentlich ein View einmal erstellt in MYSQL erhalten, oder muss ich für jeden seitenaufruf neu erstellen (aktuallisieren)?

ralphi

[dedlfix]

Tach!

kann ich diese UNION - abfragen in einem View (temp-tabelle) zusammenfassen?

Ich wüsste jetzt nichts, was dagegenspricht, hab damit aber keine großartigen Erfahrungen. (View ist keine temporäre Tabelle, sondern nur ein quasi Alias für eine Abfrage.)

Bleibt eigentlich ein View einmal erstellt in MYSQL erhalten, oder muss ich für jeden seitenaufruf neu erstellen (aktuallisieren)?

CREATE VIEW wird genauso abgelegt wie CREATE TABLE, also dauerhaft.

dedlfix.

[Siri]

Hallo,

Tabelle events:
datum , Uhrzeit, name etc.
2013-03-01, 9:00, Messe

Tabelle termine:
datum , Uhrzeit, name etc.
2013-03-01, 11:30, Kunde2

Tabelle berichte:
datum , Uhrzeit, name etc.
2013-03-01, 20:00, log2

Warum 3 Tabellen? Warum nicht:

Tabelle ereignisse
datum, uhrzeit, typ, id

Viele Grüße
Siri

[dedlfix]

Tach!

Warum 3 Tabellen? Warum nicht:
Tabelle ereignisse
datum, uhrzeit, typ, id

Die Frage hatte ich auch schon formuliert, aber dann stand da weiter unten:

Zu den Spalten: datum, name, uhrzeit gibt es noch unterschiedliche weitere Spalten, je Tabelle, die aber in dieser Abfrage nicht interessieren.

dedlfix.

[ralphi]

Hi,

Warum 3 Tabellen? Warum nicht:

Tabelle ereignisse
datum, uhrzeit, typ, id

in den einzelnen Tabellen (sind nicht nur die 3) sind jeweils noch viele unterschiedliche spalten.

tabelle privat ca. 10 weitere spalte
events ca. 30 weiter spalten
und und und
die jeweils überhaupt nix mit den anderen tabellen zu tun haben
d.h. ich hätte eine ereignisstabelle mit
ca. 150 spalten und mehr

ralphi

[Siri]

Hallo,

in den einzelnen Tabellen (sind nicht nur die 3) sind jeweils noch viele unterschiedliche spalten.
...
d.h. ich hätte eine ereignisstabelle mit
ca. 150 spalten und mehr

Ja, und? Du kannst doch über die id verknüpfen, dann musst du nicht in jeder Tabelle Datum und Uhrzeit mitschleppen. Und deine Abfrage liese (ließe?) sich ohne komplexes SQL lösen.

Viele Grüße
Siri

[ralphi]

hi

Ja, und? Du kannst doch über die id verknüpfen, dann musst du nicht in jeder Tabelle Datum und Uhrzeit mitschleppen.

Nun das ist nicht wirklich eine Lösung, beschreibt eher das Problem (Aufgabe): Mehrere Tabellen in Eine.
Ob mit WHERE ID=.. oder WHERE datum=.. ist doch egal.

dedlfix hat schon das eleganteste aufgezeigt :-)

ralphi

[dedlfix]

Tach!

in den einzelnen Tabellen (sind nicht nur die 3) sind jeweils noch viele unterschiedliche spalten.
Ja, und? Du kannst doch über die id verknüpfen, dann musst du nicht in jeder Tabelle Datum und Uhrzeit mitschleppen. Und deine Abfrage liese (ließe?) sich ohne komplexes SQL lösen.

Nö, die Daten sind schon unterschiedlich. Ihre Gemeinsamkeit ist nur, dass sie alle zu einem bestimmten Zeitpunkt stattfinden. Das allein rechtfertigt nach meinem Verständnis noch keine gemeinsame Tabelle. Ein Datumsfeld gegenüber zwei Dritteln ungenutzter Felder (Gleichverteilung angenommen).

Natürlich könnte man eine Tabelle mit Zeitpunkten und einem Typ anlegen, und pro Typ eine Tabelle mit den typspezifischen Daten. Dann müsste man aber immer anhand des Typ-Wertes entscheiden, welche Tabelle hinzugejoint werden muss. Das ist deutlich unangenehmer als eine Übersicht unterschiedlicher Tabellen mit UNION zu erzeugen.

dedlfix.

[Siri]

Hallo,

Nö, die Daten sind schon unterschiedlich. Ihre Gemeinsamkeit ist nur, dass sie alle zu einem bestimmten Zeitpunkt stattfinden. Das allein rechtfertigt nach meinem Verständnis noch keine gemeinsame Tabelle. Ein Datumsfeld gegenüber zwei Dritteln ungenutzter Felder (Gleichverteilung angenommen).

Doch, da Datum und Zeit bei einem Timer der Dreh- und Angelpunkt sind.

Was meinst du mit zwei Drittel ungenutzter Felder?

Natürlich könnte man eine Tabelle mit Zeitpunkten und einem Typ anlegen, und pro Typ eine Tabelle mit den typspezifischen Daten. Dann müsste man aber immer anhand des Typ-Wertes entscheiden, welche Tabelle hinzugejoint werden muss. Das ist deutlich unangenehmer als eine Übersicht unterschiedlicher Tabellen mit UNION zu erzeugen.

Einen Kontext gibt es doch eh immer, je nachdem, was angezeigt werden soll. Das ganze ist ja ein Timer und mit dem Timer sind verschiedenartige Ereignisse verbunden. Wenn man jetzt nur auf die events oder termine losgeht ist das mit einem JOIN doch recht bequem erledigt und an einem UNION hindert mich für komplexere Abfragen doch auch nichts.

Viele Grüße
Siri

[dedlfix]

Tach!

Nö, die Daten sind schon unterschiedlich. Ihre Gemeinsamkeit ist nur, dass sie alle zu einem bestimmten Zeitpunkt stattfinden. Das allein rechtfertigt nach meinem Verständnis noch keine gemeinsame Tabelle. Ein Datumsfeld gegenüber zwei Dritteln ungenutzter Felder (Gleichverteilung angenommen).
Doch, da Datum und Zeit bei einem Timer der Dreh- und Angelpunkt sind.

Ja, das ist aber nur eine gemeinsame Eigenschaft, wenn auch eine der wichtigsten. (Vielleicht lässt sich auch noch die eine oder andere Gemeinsamkeit finden, aber die machen das Kraut auch nicht mehr fett.)

Was meinst du mit zwei Drittel ungenutzter Felder?

Unterschiedliche Ereignistypen haben unterschiedliche Daten. Drei Typen => jeder hat n Datenfelder => 3*n Felder in einer großen Tabelle => pro Typ seine n genutzten Felder => 2/3 ungenutzte Felder.

Die Daten an sich sind unterschiedlich, auch wenn sie eine Gemeinsamkeit haben und in einem gemeinsamen System gepflegt werden. Gegenstände und Personen haben auch jeweils einen Namen, und werden vielleicht in einem einzigen System gepflegt, trotzdem gehören sie nicht in eine Tabelle, wenn der Rest der Felder jeweils unterschiedlich ist.

dedlfix.

[Siri]

Hallo,

den ersten Diskussionspunkt lasse ich einfach mal so stehen, da kann man sicher geteilter Ansicht sein.

Die Daten an sich sind unterschiedlich, auch wenn sie eine Gemeinsamkeit haben und in einem gemeinsamen System gepflegt werden. Gegenstände und Personen haben auch jeweils einen Namen, und werden vielleicht in einem einzigen System gepflegt, trotzdem gehören sie nicht in eine Tabelle, wenn der Rest der Felder jeweils unterschiedlich ist.

Reden wir aneinander vorbei?

Ich meine:
tabelle timer -> datum, uhrzeit, ereignistyp, timer-id
tabelle events -> timer-id, (name), a, b, ...
tabelle termine -> timer-id, (name), j, k, ...
tabelle berichte -> timer-id, (name), s, t, ...

Viele Grüße
Siri

[dedlfix]

Tach!

Ich meine:
tabelle timer -> datum, uhrzeit, ereignistyp, timer-id
tabelle events -> timer-id, (name), a, b, ...
tabelle termine -> timer-id, (name), j, k, ...
tabelle berichte -> timer-id, (name), s, t, ...

Das kann man so machen, aber ich sehe das nicht als sinnvoll an, ihnen die einzige Gemeinsamkeit rauszuziehen und extra zu warten.

dedlfix.

[Siri]

Hallo,

Das kann man so machen, aber ich sehe das nicht als sinnvoll an, ihnen die einzige Gemeinsamkeit rauszuziehen und extra zu warten.

Dann gehen wir jetzt einfach mit geteilter Meinung ins Wochenende ;-)

Viele Grüße
Siri