Query an Tabellen deren Name selbst Ergebnis einer Query sind

[flugwaps]

Hallo liebe Forumsmitglieder-Innen,

In prozeduralen Sprachen (php, bash etc ...) ist das für mich kein Problem,
aber ich möchte gern einen hübschen sql - Einzeiler.

Hier fehlt mir ein Lösungsansatz in SQL.

- eine DB hat die Tabellen "Items" und beliebig viele Tabellen "ItemX"
- ich möchte eine query auf alle tables ItemX (zb. max(ItemsX.value2)) schicken
welche zuvor von einer query aus Items als Ergebnis geliefert wurde (z.B. Items.ItemName like %temperatur%)
ItemId ist eine int-Zahl, der table-name für die zweite query muß also noch "gebaut" werden : "Item""$Items.ItemId"

Struktur :
table Items
- ItemId,ItemName

table Items1
- value1,value2 ....

table Items2
- value1,value2 ....

...
table ItemsN
- value1,value2 ....

Bitte schubst mich mal in die passende Richtung.

Danke und schönes WE

 

[akretschmer]

Was Du da versuchst und völlig falsch angehst nennt sich Partitioning.

5.11. Table Partitioning

 

[flugwaps]

Hallo und danke für die flotte Antwort,
leider ist die DB und deren Tabellenstruktur (sql interface von openhab) vorgegeben, ich kann/will da nur "abgreifen".

 

[akretschmer]

Dann brauchst Du dies: 42.5. Basic Statements

Aber eigentlich eher sowas: Holz Baseballschläger 18 „Lumber“ - Holz - 18 in
zur Erziehung der Leute, die das verpfuscht haben.

 

[flugwaps]

execute Das freut den "old style programmer" . Danke. probier ich aus.

(Ich will aber trotzdem openhab in Schutz nehmen, die SQL Anbindung ist nicht die Kernaufgabe des Systems. Und in eine DB dynamisch zur Laufzeit Tabellen hinzufügen und in einer "Indextabelle" verwalten ist auf den ersten Blick nicht falsch.)

Bitte lassen wir es dabei bewenden ...

Alles gut ! Schönes WE !

 

[akretschmer]

Und in eine DB dynamisch zur Laufzeit Tabellen hinzufügen und in einer "Indextabelle" verwalten ist auf den ersten Blick nicht falsch.

Nur auf den ersten Blick. Beim zweiten schon nicht mehr.

 

[dabadepdu]

Naja, um openhup Leute zu erwischen, braucht man sicher schon was längeres oder man wirft den Baseballschläger.
Aber mal ernst:
"Oneliner" ist wahrscheinlich keine gute Idee. Einfach weil es keine gute Idee ist, alle Daten zu "vermischen" oder besser gesagt, gleich zu behandeln.

Die Möglichkeiten wurden ja schon genannt, die man in Postgres per dynamischem SQL hat.
Ich kenne die Interna von openhub nicht, aber wenn es das ist, wonach es klingt, findet man dort alle(?), beliebige Daten zum Thema, von der Infrastruktur, über konkrete Devices, ihre Fähigkeiten und Schalter, über (aktuellen) die Zustände bis hin zu unendlichen Verbrauchs und Messdaten.
An der Stelle würde ich ansetzen und nicht mit Einzeilern anfangen, sondern mit der Abbildung konkreter Informationen.
Am besten per View, ein View für ein Thema, etwa so
Create View light_switch as Select .. from item where
Create View light_switch_state as Select .. from ..
Create View light_switch_history as Select

Prinzip dürfte klar sein, kann variiert werden und ist ausbaufähig. Dabei muss man zum Aufbau der Views nun jeweils die openhup Tabellen so oft wie nötig abfragen bzw. joinen.

Eine andere Frage wäre natürlich, wo und wie diese Art "Interface" entstanden ist / definiert wurde und ob es die Primärquelle ist. Mglw. hat man da an irgendeiner Stelle bessere Karten.