SELECT auf *viele* gleichartige Tabellen

Hallo,

ich muß auf einem System mit MySQL 4.0.18 Daten aus vielen völlig gleich
aufgebauten Tabellen auslesen und summieren. Ich habe pro Tag eine eigene
Tabelle (nicht über den Sinn diskutieren, ich kann nichts daran ändern)
in der User, Domains und Bytes stehen

table20060301
-------------
john google.de 132098019283
bill ebay.com 5984949312
vera box,sk 98459689456

table20060302
-------------
mike google.de 87897875283
bill ebay.com 9849493133
mick yahoo.at 8763638494

..
..
..

table20060331
-------------
sepp google.at 48732847834
paul debian.org 878378784
hans suse.de 8789099909


Als Ergebnis will ich einmal alle Domains und Bytes für einen User, aber auch
Domains und Bytes für alle User. Klar, ich kann pro Tabelle einen Select
machen und das ganze im Programmcode addieren und ausgeben. Aber gibt es auch
eine MySQL-Lösung? Gibt es eine Lösung a la "SELECT domain, bytes GROUP BY
domain FROM table200603*"? Ich habe gegoogelt und gekoflert, aber nichts ge-
funden.

Danke!


Klaus

Re: SELECT auf *viele* gleichartige Tabellen

Andreas
--
Andreas Kretschmer
Linux - weil ich es mir wert bin!
GnuPG-ID 0x3FFF606C http://wwwkeys.de.pgp.net
Deutsche PostgreSQL User Group: http://pgug.de

Re: SELECT auf *viele* gleichartige Tabellen

Am Mon, 13 Mar 2006 15:57:53 +0100 schrieb Andreas Kretschmer:

> > ich muß auf einem System mit MySQL 4.0.18 Daten aus vielen völlig gleich
> > aufgebauten Tabellen auslesen und summieren. Ich habe pro Tag eine eigene

> Du suchst UNION.

Die Tabellennamen sehen so aus:

| fiat_http_proxy16_netz_sbs_de_20060309235700041 |
| fiat_http_proxy16_netz_sbs_de_20060310235700849 |
| fiat_http_proxy16_netz_sbs_de_20060311235700621 |
| fiat_http_proxy16_netz_sbs_de_20060312235700402 |

Pro Tag habe ich 11 Tables, eine Monatsauswertung muss also 11 * 31 Tables
auswerten. Ich habs noch nicht versucht, aber was meint MySQL zu einem Statement
das so lang ist?


Klaus

Re: SELECT auf *viele* gleichartige Tabellen

Hi Klaus

Klaus Kettner wrote:
> Am Mon, 13 Mar 2006 15:57:53 +0100 schrieb Andreas Kretschmer:
>>> ich muß auf einem System mit MySQL 4.0.18 Daten aus vielen völlig gleich
>>> aufgebauten Tabellen auslesen und summieren. Ich habe pro Tag eine eigene
>> Du suchst UNION.
> Die Tabellennamen sehen so aus:
> | fiat_http_proxy16_netz_sbs_de_20060309235700041 |
> | fiat_http_proxy16_netz_sbs_de_20060310235700849 |
> | fiat_http_proxy16_netz_sbs_de_20060311235700621 |
> | fiat_http_proxy16_netz_sbs_de_20060312235700402 |
> Pro Tag habe ich 11 Tables, eine Monatsauswertung muss also 11 * 31 Tables
> auswerten. Ich habs noch nicht versucht, aber was meint MySQL zu einem Statement
> das so lang ist?

Du könntest Views einsetzen, falls du an die Grenzen kommen solltest.

Ansonsten ist die Maximale Query Length abhängig von max_allowed_packet,
welches regulär auf 1 MB liegt. Wenn du also 10000 solcher Tabellen
zusammenhängst, kommst an die Grenzen des Default-Wertes. Dieser liesse
sich aber noch immer vergrössern bis maximal 1 GB, also ausgehend von ca
100 Zeichen pro Tabelle ergibt das immerhin 10 Mio Tabellen, die du
durch den SQL Parser jagen kannst.

Problematischer wird es dannmit dem Query Buffer, RAM, etc.

Grundsätzlich solltest du dir Gedanken über die verwendeten Technologien
machen. Und falls du ein RDBMS benutzen willst (ich kenne deine
eigentlich Aufgabe nicht), solltest du dir über das DB-Design Gedanken
machen.

HTH, Johannes

Re: SELECT auf *viele* gleichartige Tabellen

Klaus Kettner wrote:
> Am Mon, 13 Mar 2006 15:57:53 +0100 schrieb Andreas Kretschmer:
>
>> > ich muß auf einem System mit MySQL 4.0.18 Daten aus vielen völlig gleich
>> > aufgebauten Tabellen auslesen und summieren. Ich habe pro Tag eine eigene
>
>> Du suchst UNION.
>
> Pro Tag habe ich 11 Tables, eine Monatsauswertung muss also 11 * 31 Tables
> auswerten. Ich habs noch nicht versucht, aber was meint MySQL zu einem Statement
> das so lang ist?

Abgesehen davon, daß es erstmal langsam wird und schließlich
nicht mehr das Gewünschte tut, wird MySQL sich vermutlich darüber
ärgern, daß weder RSP (remote strangulation protocol) noch ein
tactile feedback device [1] implementiert sind.

Ansonsten finde ich deine Frage etwa so sinnvoll wie die nach
Empfehlungen, wie man mit einem Hammer eine Schraube möglichst
fest bekommt (incl. dem Hinweis, daß man keine Diskussion über
die Existenz geeigneterer Werkzeuge wünscht).

[1] http://ars.userfriendly.org/cartoons/?id=20021103


XL

Re: SELECT auf *viele* gleichartige Tabellen

Am Mon, 13 Mar 2006 16:45:56 +0100 schrieb Johannes Vogel:

> Du könntest Views einsetzen, falls du an die Grenzen kommen solltest.

ich hätte nicht gedacht, daß so lange Abfragen erlaubt sind, wieder was
gelernt - deshalb hatte ich UNION von Anfang an ausgeschlossen. Die Daten
eines Monats (344 Tables) ergeben eine Abfrage von ca. 40 kB, die läuft
sauber durch.

Aber zum UNION habe ich noch eine Frage:

(select domain, sum(bytes) as b from f20060128235700719 group by domain) UNION
(select domain, sum(bytes) as b from f20060129235700500 group by domain) UNION
(select domain, sum(bytes) as b from f20060130235700280 group by domain) UNION
(select domain, sum(bytes) as b from f20060131235700087 group by domain)
ORDER BY domain LIMIT 10;

ergibt folge Ausgabe:

+----------------+---------+
| domain | b |
+----------------+---------+
| zzzebra.de | 4696 |
| zzz.at | 85971 |
| zzwancor.ch | 384720 |
| zyxeltech.de | 2020699 |
| zyxel.de | 256442 |
| zyn.de | 252518 |
| zylomgames.com | 51147 |
| zylom.de | 478 |
| zylom.de | 264 |
| zylom.com | 43396 |
+----------------+---------+
10 rows in set (1.20 sec)


Nun möchte ich aber noch die Domains summieren, so wie das bei den einzelnen
SELECTS mit sum(bytes) passiert ist. Wie kriege ich zylom.de und zylom.de
addiert?


Klaus

Re: SELECT auf *viele* gleichartige Tabellen

Am Mon, 13 Mar 2006 17:18:19 +0100 schrieb Axel Schwenke:

Hi,

> Abgesehen davon, daß es erstmal langsam wird und schließlich
> nicht mehr das Gewünschte tut, wird MySQL sich vermutlich darüber
> ärgern, daß weder RSP (remote strangulation protocol) noch ein
> tactile feedback device [1] implementiert sind.

OK, es ist langsam, ich habe es gerade mit 344 Tabellen getestet und
es lief auf einer wirklich schnellen Kiste 9 Minuten. Macht nix, muss
nur 1 x pro Monat laufen. Keine Sorge, TFD sitzt nebenan, heisst Chef.

> Ansonsten finde ich deine Frage etwa so sinnvoll wie die nach
> Empfehlungen, wie man mit einem Hammer eine Schraube möglichst
> fest bekommt (incl. dem Hinweis, daß man keine Diskussion über
> die Existenz geeigneterer Werkzeuge wünscht).

Du hast natürlich recht, ein besseres Design von Anfang an hätte hier
geholfen, aber manchmal braucht man einfach eine pragmatische Lösung
für ein Problem, hat nur einen Hammer zur Hand. Dumm wenn dann der
Auftraggeber kein Verständnis (=Budget) für das Neudesign des Möbel-
stücks hat.

Habe mein Problem mit vielen vielen Unions und einer Zwischentabelle
gelöst, danke euch.


Klaus

Re: SELECT auf *viele* gleichartige Tabellen

Andreas
--
q: why do so many people take an instant dislike to mysql?
a: it saves time (oicu in #postgresql)
Explaining the concept of referential integrity to a mysql user is like
explaining condoms to a catholic (Shadda in #postgresql)

Re: SELECT auf *viele* gleichartige Tabellen

Hi Andreas

Andreas Kretschmer wrote:
> begin Klaus Kettner wrote:
>> Nun möchte ich aber noch die Domains summieren, so wie das bei den einzelnen
>> SELECTS mit sum(bytes) passiert ist. Wie kriege ich zylom.de und zylom.de
>> addiert?
> Du erzeugst Dir mit dem UNION quasi eine neue Tabelle, über der Du
> summierst/gruppierst. Sollte MySQL können.

s/sollte/tut/ sozusagen. Und zwar kennt MySQL seit 4.1.x Subselects.

> Das Du ein komplett kaputtes Design hast, habe Dir ja nun schon andere
> bestätigt.

Das ist ja nicht in Frage zu stellen. Gerade in solchen Projekten
übernimmt man Daten von Vorgängern oder anderen Mitarbeitern.

--> Klaus
Vielleicht willst du dir stattdessen eine View anlegen (ab MySQL 5.0),
worin du diese enorme Abfrage abbildest. Dann kannst du obendurch mal
mit einem brauchbaren, virtuellen Design deine Applikation erstellen und
vielleicht im Nachhinein doch noch die Daten anders designen. IMHO kann
MySQL Views auch cachen...

HTH, Johannes

Re: SELECT auf *viele* gleichartige Tabellen

Andreas
--
q: why do so many people take an instant dislike to mysql?
a: it saves time (oicu in #postgresql)
Explaining the concept of referential integrity to a mysql user is like
explaining condoms to a catholic (Shadda in #postgresql)

Re: SELECT auf *viele* gleichartige Tabellen

Andreas
--
q: why do so many people take an instant dislike to mysql?
a: it saves time (oicu in #postgresql)
Explaining the concept of referential integrity to a mysql user is like
explaining condoms to a catholic (Shadda in #postgresql)

Re: SELECT auf *viele* gleichartige Tabellen

Klaus Kettner wrote:
> Als Ergebnis will ich einmal alle Domains und Bytes für einen User, ab=
er auch=20
> Domains und Bytes für alle User. Klar, ich kann pro Tabelle einen Sele=
ct=20
> machen und das ganze im Programmcode addieren und ausgeben. Aber gibt es=
auch
> eine MySQL-Lösung?=20

Helfen Dir vielleicht MERGE-Tables?

http://dev.mysql.com/doc/refman/4.1/en/merge-storage-engine. html

Re: SELECT auf *viele* gleichartige Tabellen

Hi Andreas

Andreas Kretschmer wrote:
> begin Johannes Vogel wrote:
>> Vielleicht willst du dir stattdessen eine View anlegen (ab MySQL 5.0),
> Btw.: er nutzt 4.x. Dieser Hinweis ist also genauso flasch/richtig, als
> wenn ich auf PG verwiesen hätte, was Views schon immer kann.

Stimmt. MySQL 5.0 zu verwenden liegt aber näher als PG.
Ausserdem lese ich bei der verwendeten NG '.mysql'. Fällt der Groschen?

Ist etwa dasselbe, wie wenn du in ner Trabi-NG (immer diese
Autobeispiele!) erzählst, dass der Ferrari all das auch schon längst
kann und wahrscheinlich beim Trabi all das auch in etwa gleich
funktionieren sollte, wie du's beim Ferrari machen würdest. Ob du wohl
auf den Honig um den Mund anspringst? :-) Letztendlich kochen alle nur
mit Wasser.

>> worin du diese enorme Abfrage abbildest. Dann kannst du obendurch mal
> Was ändert sich einklich dabei? Richtig, nix. Die Abfrage bleibt
> dieselbe.

Ja, aber die Applikation könnte bereits mit dem neuen Design arbeiten,
während die Daten noch in der alten Struktur vorliegen. Das wäre doch
eigentlich eine ganz praktische Übergangsglösung. Und wenn dann die
Applikation steht und der Chef sieht, dass man gute Arbeit erledigen
kann, ist er vielleicht auch gewillt, das DB-Design ändern zu lassen.

Grüess, Johannes

Re: SELECT auf *viele* gleichartige Tabellen

Am 13 Mar 2006 23:21:58 GMT schrieb Sven Paulus:

Hi Sven,

> Helfen Dir vielleicht MERGE-Tables?
> http://dev.mysql.com/doc/refman/4.1/en/merge-storage-engine. html

vielen Dank! Das ist ein sehr guter Hinweis! Ich habe zwar jetzt eine
funktionierende Lösung mit UNION, aber die MERGE-Tabellen klingen für
mich wesentlich eleganter. Werde gleich mal testen.


-kk-

Re: SELECT auf *viele* gleichartige Tabellen

Am Mon, 13 Mar 2006 19:02:56 +0100 schrieb Johannes Vogel:

> Vielleicht willst du dir stattdessen eine View anlegen (ab MySQL 5.0),
> worin du diese enorme Abfrage abbildest.

leider kann ich zum einen nicht auf v5 upgraden (Kundenserver), zum anderen
ist die Abfrage nicht statisch, sondern wird durch den Benutzer bestimmt,
der über ein Webinterface bestimmt, welche Tabellen er ausgewertet haben
will.


-kk-

Re: SELECT auf *viele* gleichartige Tabellen

Klaus Kettner wrote:
> Am 13 Mar 2006 23:21:58 GMT schrieb Sven Paulus:
>
> Hi Sven,
>
>> Helfen Dir vielleicht MERGE-Tables?
>> http://dev.mysql.com/doc/refman/4.1/en/merge-storage-engine. html
>
> vielen Dank! Das ist ein sehr guter Hinweis! Ich habe zwar jetzt eine
> funktionierende Lösung mit UNION, aber die MERGE-Tabellen klingen für
> mich wesentlich eleganter.

Je nach Aufgabenstellung sind MERGE Tables keine Lösung. Das Problem
ist, daß ein Teil des Keys im Tabellennamen steckt. Ich verstehe das
Datenmodell des OP so, daß es einen dreiteiligen Key (Datum, User,
Domain) gibt, der jeweils einen INTEGER Wert referenziert.

Wenn ein Teil des Keys (hier: Datum) im Tabellennamen steckt, bekommt
man den per SQL da nicht mehr raus. Man kann ihn allerdings wieder in
ein SQL-Result reintun. Etwa so:

SELECT '2006-03-01' AS when, bytes FROM table20060301
UNION
SELECT '2006-03-02', bytes FROM table20060302
UNION
....

allerdings kann man mit diesem Ergebnis nicht viel anfangen. Evtl.
möchte man ja per GROUP BY MONTH(when) aggregieren. Dazu müßte man
aber schon eine VIEW für obiges Statement anlegen.

In MERGE Tables verliert man den 'Datum' Teil des Keys ganz. Es gibt
keine Information, aus welcher der unterliegenden Tabellen ein
Datensatz stammt, den man aus einer MERGE Table liest.

Womöglich ist das ja gar kein Problem. Nur frage ich mich dann, wozu
die 'Datum' Information überhaupt in den Tabellennamen codiert wird.
Einfach alles in eine Tabelle und fertig.


XL