SUM() über mehrere Tabellen

[scrat1979]

Hallo zusammen,

... und schon wieder habe ich zu meiner (einfachen) Frage keine Lösung. Helft mir bitte auf die sprünge :-)

Ich möchte ganz einfach alle Datensatz von meheren Tabellen zusammenzählen. Sämtliche Versuche meinerseits mittels sum() und count() sind leider fehlgeschlagen :-(

SCRaT

[Bernhard Geyer]

Und was spricht dagegen das Clientseitig durchzuführen?

[shmia]

SQL-Code:

SELECT SUM(anzahl) AS AnzahlTotal FROM
(
SELECT SUM(Feld1) AS Anzahl FROM Tabelle1
UNION ALL
SELECT SUM(Feld2) AS Anzahl FROM Tabelle2
)

Wenn die Tabellen 1 und 2 die gleiche Struktur haben, dann ist dein Datenbankdesign fehlerhaft. :warn:

[mkinzler]

Wie sehen die Tabellen bzw das gewünschte Ergebnis aus?

[scrat1979]

Hallo und vielen Dank für die Vorschläge!

Zitat:

Zitat von Bernhard Geyer

Und was spricht dagegen das Clientseitig durchzuführen?

Mein Ehrgeiz und mein Interesse mich in SQL einzuarbeiten. Aber prinzipiell gebe ich Dir natürlich
Recht - so hatte ich es bisher auch gelöst :-)

Zitat:

Zitat von shmia

SQL-Code:

SELECT SUM(anzahl) AS AnzahlTotal FROM
(
SELECT SUM(Feld1) AS Anzahl FROM Tabelle1
UNION ALL
SELECT SUM(Feld2) AS Anzahl FROM Tabelle2
)

Wenn die Tabellen 1 und 2 die gleiche Struktur haben, dann ist dein Datenbankdesign fehlerhaft. :warn:

Danke, funktioniert einwandfrei. Natürlich handelt es sich um verschiedene Tabellenstrukturen (Hatte ich irgendwo erwähnt, das die Tabellen dieselbe Struktur haben?!?!) Genauer gesagt ist es eine Fotodokumentationssoftware für eine Arztpraxis. Mittels Export-Funktion sollen die markierten Datensätze in eine neue Datei (=Datenbankdatei) geschrieben werden. Die jeweils markierten Datensätze der verschiedenen Tabellen (Patienten, Diagnosen, Bilder) möchte ich für eine Fortschrittsanzeige zusammenzählen, weiter nichts :wink:

Nochmals Dickes :cheers:

Man liest sich,

SCRaT

[Bernhard Geyer]

Zitat:

Zitat von scrat1979

Mein Ehrgeiz und mein Interesse mich in SQL einzuarbeiten. Aber prinzipiell gebe ich Dir natürlich
Recht - so hatte ich es bisher auch gelöst :-)

Interesse schön und gut. Aber dieses einfache Select stellt eine nicht unerhebliche Belastung für einen SQL-Server dar, da er mindestens den kompletten Primärindex durchlaufen muss. Auch wenn du sagst: Sowas müßte doch ganz einfach sein: Nicht für transaktionsfähige Datenbanken wenn die Tabellen Eintrage beinhalten welche schon langsam an die Mio.-Grenze reichen. Da kann ein solche "einfaches" schon mal für eine Tabelle ein Minute brauchen. Und ob ADS hier zaubern kann?

[mkinzler]

Wenn die tabellen in der Struktur auch nicht komplett übereinstimmen, sondern nur zum teil könnte man versuchen Gleiches zusammenzufassen.

[scrat1979]

Zitat:

Zitat von Bernhard Geyer

Zitat:

Zitat von scrat1979

Mein Ehrgeiz und mein Interesse mich in SQL einzuarbeiten. Aber prinzipiell gebe ich Dir natürlich
Recht - so hatte ich es bisher auch gelöst :-)

Interesse schön und gut. Aber dieses einfache Select stellt eine nicht unerhebliche Belastung für einen SQL-Server dar, da er mindestens den kompletten Primärindex durchlaufen muss. Auch wenn du sagst: Sowas müßte doch ganz einfach sein: Nicht für transaktionsfähige Datenbanken wenn die Tabellen Eintrage beinhalten welche schon langsam an die Mio.-Grenze reichen. Da kann ein solche "einfaches" schon mal für eine Tabelle ein Minute brauchen. Und ob ADS hier zaubern kann?

Auch wenn meine Datenbank diese Dimension niemals erreichen wird ist es ein nachvollziehbarer Einwand. Ich werde mal einige 10.000 Dummy-Einträge machen und dann nach der besten Lösung suchen. Eventuell könnte ich auch bei der DB-Komponente selbst den Filter (Feld Export = True) setzen. Ich glaube dann werden die Datensätze ohne erneute Abfrage gefiltert und das müsste dann wohl schneller gehen. Danke für den Tip, werde es wohl dann doch Clientseitig lösen. Aber immerhin habe ich wieder was dazugelernt :angel:

Zitat:

Zitat von mkinzler

Wenn die tabellen in der Struktur auch nicht komplett übereinstimmen, sondern nur zum teil könnte man versuchen Gleiches zusammenzufassen.

Nein, Nein. Die beiden Tabellen haben komplett verschiedene Strukturen. Es werden hier keine Daten redundant gespeichert. Es ging lediglich um die ANZAHL der Datensätze aller 3 (unterschiedlich strukturierten!) Tabellen zusammen - oder habe ich Dich mißverstanden :gruebel:

Grüsse,
SCRaT

[mkinzler]

Es ging mir nicht umd die Redundanz, sondern die ähnliche Struktur

z.B.

Tabelle1
A, B, C

Tabelle2
B, C, D

Tabelle3
C, D, E

->

Tabelle
A, B, C, D, E

oder

Tabelle1
A, B, C, D

Tabelle2
A, B, C, E

Tabelle3
A, B, C, F

->

Tabelle
A, B, C

Tabelle1
TID, D

Tabelle2
TID, E

Tabelle3
TID, F

[DGL-luke]

...Also jede DB sollte eine einigermaßen performante Funktion haben, um die Anzahl der Datensätze in einer Tabelle zu ermitteln, bzw. die Anzahl ständig mitkeschen... :gruebel:

@mkinzler: Er hat eine Tabelle Äpfel, eine Tabelle Birnen, und eine mit Gemüse. Er will nur wissen wie viel Obst und Gemüse er hat.
Er will nicht erst Äpfel und Birnen mit dem Gemüse in einen Eimer schmeißen und dann zählen.

[mkinzler]

Ich kannte ja seine Struktur nicht, war ja nur ein theoretischer Ansatz.

[DGL-luke]

Er hat ja schon zweimal gesagt, er will deinen theoretischen Ansatz nicht, also geh weg! :mrgreen: :duck:

</humor>

[mkinzler]

@scrat1979: Hiermit entschuldige ich mich für mein dummes Besserwissen.

[scrat1979]

Zitat:

Zitat von DGL-luke

Er hat ja schon zweimal gesagt, er will deinen theoretischen Ansatz nicht, also geh weg! :mrgreen: :duck:

</humor>

Hmm, naja. Das habe ich nicht gesagt :-) Aber jetzt weiß ich was mkinzler gemeint hat....

Zitat:

Zitat von mkinzler

@scrat1979: Hiermit entschuldige ich mich für mein dummes Besserwissen.

... das habe ich niemals behauptet! :oops:. - im Gegenteil: Dein "Besser" Wissen im wahrsten Sinne des Wortes fasziniert mich sogar (und das nicht nur in meinen Threads) :thumb:

Zurück um Topic:
Es handelt sich bei den Tabellen sozusagen um Master->Detail Tabellen (1 Patient = x Diagnosen, Pro Diagnose wiederum X Bilder). Gibt es da eine sinnvolle Möglichkeit alles in eine Tabelle zu schreiben? IMHO müsste man doch bei der 6. Diagnose eines Patienten wiederum Vorname, Nachname etc. in den Datensatz speichern (und die x Bilder pro Diagnose sind da ja noch gar nicht dabei). Hatte mal was von atomarer Tabellenstruktur gelesen (hoffe das war das Wort und der richtige Zusammenhang :-) ).


Liebe Grüsse und bis morgen!

SCRaT

P.S.: Ein Post meiner Tabellenstrukturen folgt morgen :twisted:

[mkinzler]

Mein letzter Beitrag war auch eher ironisch gemeint

[daddy]

Die Gesamtanzahl der Datensätze aller 3 Tabellen sollte sich doch mit folgender Abfrage ermitteln lassen:

SQL-Code:

Select (count (*) + (Select Count (*) from Table2) + (Select Count (*) from Table3)) as GesamtAnzahl from Table1

Gruß Daddy

[Bernhard Geyer]

Zitat:

Zitat von DGL-luke

...Also jede DB sollte eine einigermaßen performante Funktion haben, um die Anzahl der Datensätze in einer Tabelle zu ermitteln, bzw. die Anzahl ständig mitkeschen... :gruebel:

Wenn du entsprechende Funktionen weist: her damit. Bisher habe ich nur Statistik-Infos gefunden die irgendwann mal aktualisiert werden und nur Näherungswerte beinhalten.

[DGL-luke]

Ich würde mal sagen, wenn du keine WHERE-Klausel dazutust, also einfach das von daddy probierst, wird die datenbank so intelligent sein, und nicht den kompletten index durchlaufen.

[Bernhard Geyer]

Jedenfalls kann ich bei MS SQL-Server (2000) und Oracle (8) sagen das bei zu schwachbrüstigen Rechner (verglichen mit DB-Größe) eine SELECT Count(*) from <TabellenName> schon mal 'ne Minute dauern kann.

[DGL-luke]

...das enttäuscht mich. Ein einfaches Int64 pro Tabelle zu speichern und bei Bedarf zu inkrementieren wär ja nicht so schwer (vor allem wenn man sql-intern sowieso die affected rows vorhält).

[Bernhard Geyer]

Hat mich auch enttäuscht. Aber dies müsste ja auch im Rahmen von Transaktionen gepflegt werden ...