Performance-Frage: Abfrage mehrerer Tabellen

[Helmuth]

Hallo,

ich möchte die Profis (da ich keiner bin) hier fragen wie sie folgendes lösen würden:

Ich habe eine Datenbank mit je einer Tabelle pro Stadt, darin zwischen 0 und 5000 Einträgen z.B.:
 objekt_id | email | text | etc
Normal wird immer nur die Tabelle der jeweiligen Stadt abgefragt - für eine Übersicht benötige ich nun aber die Abfrage aller Tabellen nach einer Email-Adresse.

Also etwas wie: select * from allen Tabellen where email = 'bla'

Tabellen werden es mit der Zeit immer mehr, also 2 bis 100. Es gibt eine Übersichts-Tabelle in der eingetragen welche Städte-Tabellen es bereits gibt.

Wie ist die performanteste Lösung eurer Meinung nach? Alle Tabellen joinen, einzeln abfragen,...

Danke für eure Hilfe,

Helmuth

[Cheatah]

Hi,

Ich habe eine Datenbank mit je einer Tabelle pro Stadt,

das ist Quatsch.

Tabellen werden es mit der Zeit immer mehr,

Nein, werden es nicht. Für gleichartige Daten hast Du genau *eine* Tabelle. Sofern also die Tabellen pro Stadt nicht strukturell signifikant unterschiedlich sein soll, ist Dein DB-layout grob defekt.

Cheatah

[Ilja]

yo,

Ich habe eine Datenbank mit je einer Tabelle pro Stadt,

das ist Quatsch.

Tabellen werden es mit der Zeit immer mehr,

Nein, werden es nicht. Für gleichartige Daten hast Du genau *eine* Tabelle. Sofern also die Tabellen pro Stadt nicht strukturell signifikant unterschiedlich sein soll, ist Dein DB-layout grob defekt.

erstaunlich wie oft wir zu unterschiedlichen ergebnissen kommen. aus gründen der performance ist es durchaus üblich, tabellen zu teilen, zumal wenn es so ist, wie er schreibt, dass die daten in aller regel nicht zusammen abgerufen werden, sondern nur eine stadt betreffen. vielleicht wäre von deiner seite aus mal der blick in andere richtungen angebracht, als immer nur die eigene meinung als die einzige anzusehen.

Ilja

[Cheatah]

Hi,

erstaunlich wie oft wir zu unterschiedlichen ergebnissen kommen.

nö, erstaunlich finde ich das nicht, sondern eher natürlich. Wäre doch langweilig, wenn es nur einen Weg gäbe ;-)

aus gründen der performance ist es durchaus üblich, tabellen zu teilen,

Aus meiner Erfahrung mit diversen Schemata, die über mehrere Dutzend Tabellen mit teilweise vielen Millionen Datensätzen verfügen, muss ich sagen, dass das alles andere als üblich ist.

zumal wenn es so ist, wie er schreibt, dass die daten in aller regel nicht zusammen abgerufen werden, sondern nur eine stadt betreffen.

Du weißt aber schon, dass der Begriff "Index" nicht zwangsläufig für etwas steht, das nicht jeder bekommen darf?

vielleicht wäre von deiner seite aus mal der blick in andere richtungen angebracht, als immer nur die eigene meinung als die einzige anzusehen.

Kommt darauf an. Bei einer _fachlichen_ Meinung kann ich entweder beurteilen, ob sie "die einzige" ist, oder ich tue es nicht. Und, bei aller Liebe: Die Behauptung, es sei "üblich", aus Performance-Gründen eine normalisierte Tabelle in mehrere aufzuteilen, halte ich fachlich für Anfänger-Gefasel. Wenn Du von Einzelfällen geredet hättest, hätte ich das akzeptiert und für irrelevant erklärt, da es kein Indiz dafür gibt, dass hier ein solcher vorliegt; aber in dieser allgemeinen Form gehört Deine Behauptung IMHO in den Müll.

Cheatah

[Ilja]

yo,

nö, erstaunlich finde ich das nicht, sondern eher natürlich. Wäre doch langweilig, wenn es nur einen Weg gäbe ;-)

und genau darum geht es doch Cheatah, dass man andere wege mal mitverfolgt und nicht immer alles gleich als quatsch abtut, nur weil man selbst sich darauf keinen reim machen kann.

Aus meiner Erfahrung mit diversen Schemata, die über mehrere Dutzend Tabellen mit teilweise vielen Millionen Datensätzen verfügen, muss ich sagen, dass das alles andere als üblich ist.

über das wort "üblich" kann man sich gerne streiten. es bleibt aber dabei, das es in der praxis (wenn auch nicht von dir) eingesetzt wird uns somit in meinen augen kein quatsch ist, wie du es betitelst hast.

Du weißt aber schon, dass der Begriff "Index" nicht zwangsläufig für etwas steht, das nicht jeder bekommen darf?

du weißt aber schon, dass nicht jedes dbms einen bitmap index beherscht und ein b-tree index nicht in allen fällen eingesetzt werden kann ? ein index ist kein allheilmittel, vielleicht gibt es gute gründe, dass ein index allein nicht reicht, vielleicht weil die ergebnismenge zu gross ist, vielleicht die kardinalität nicht geeignet ist, wer weiß. hast du ihn gefragt ?

Und, bei aller Liebe: Die Behauptung, es sei "üblich", aus Performance-Gründen eine normalisierte Tabelle in mehrere aufzuteilen, halte ich fachlich für Anfänger-Gefasel. Wenn Du von Einzelfällen geredet hättest, hätte ich das akzeptiert und für irrelevant erklärt, da es kein Indiz dafür gibt, dass hier ein solcher vorliegt; aber in dieser allgemeinen Form gehört Deine Behauptung IMHO in den Müll.

wenn dich das wort üblich stört, dann will ich darauf nicht herum reiten. es ging mir eher um die aussage, dieses vorgehen als quatsch zu bezeichnen und das "grundsätzlich" als fehler im design abtut, ohne mal nachzufragen, warum es so gelöst wurde und auch welche probleme man gestossen ist. und auch wenn man sich mal irrt, dann ist man auch nicht gleich ein anfänger.

was ich als anfängerhaft bezeichnen würde, dann von sich selbst so sehr überzeugt zu sein, dass man nicht noch mal nachfragt, warum er zu den ergebnissen gekommen ist. und ich gebe ganz offen zu, ich habe mit deiner art ein problem. auch wenn du fachlich sicherlich in den meisten fällen recht hast. so zu tun, als wenn man immer recht hat, und nur weil einem keine andere möglichkeit einfällt, dann so zu tun, als wenn es keine geben würde, das nervt. gerade in sachen datenbanken hast du dich oft genug geirrt.

Ilja

[stareagle]

Hallo,

ich möchte die Profis (da ich keiner bin) hier fragen wie sie folgendes lösen würden:

Ich habe eine Datenbank mit je einer Tabelle pro Stadt, darin zwischen 0 und 5000 Einträgen z.B.:
objekt_id | email | text | etc

Das ist schon dein Problem. Du brauchst in diesem Fall nur eine Tabelle:

objekt_id | email | text | etc | stadt

Event. die Städte noch in eine extra Tabelle, und nur die stadtid verwenden:

objekt_id | stadtid | email | text | etc |

und

stadtid | stadt

Tipp: Beschäftige dich mit relationalen Datenbanken, insbesondere der Normalisierung selbiger.

Gruß

Stareagle

[Ilja]

yo,

Wie ist die performanteste Lösung eurer Meinung nach? Alle Tabellen joinen, einzeln abfragen,...

zu joinen schon mal gar nicht, wenn überhaupt dann ist hier UNION der richtige operator. und da deine tabellen dynamisch wachsen, sich aber hoffentlich in der struktur gleichen, dann würde ich als erstes eine abfrage über die tabelle machen, welche die tabellennamen beinhaltet und dann eine zweite abfrage, welche die UNION abfrage zusammenbaut und dann abschickt. das wären insgesamt zwei abfragen, damit läßt du das dbms am leben.

Ilja