nicht angemeldet
MYSQL Optmieren
Hallo, hab da noch eine weitere Frage,
Was findet Ihr ist performancetechnisch besser
Habe 2 Tabellen die identisch sind. das eine ist die Haupttabelle mit den aktuell gültiegen Datensatz, das andere eine History Tabelle.
Diese habe ich zur zeit mit einer Merge Tabelle verbunden und überlege was aus sicher der Geschwindigkeit besser ist.
Die Merge Tabelle oder ein view mit SELECT AS... tabelle1 UNION tabellehistory
Das Problem ist das manche Abfragen nur den aktuellen Datensatz brauchen, den ich aus der Tabelle mit den aktuellen Datensätzen hole. Manche Abfragen erfordern aber das ich den Datensatz wähle der zur angegeben Datum gültig war
Gruß Daniel
-
Habe 2 Tabellen die identisch sind. das eine ist die Haupttabelle mit den aktuell gültiegen Datensatz, das andere eine History Tabelle.
Finde ich OK, wenn die historisierten Datensätze selten benötigt werden, ansonsten besser mit einer Tabelle kommen.
Diese habe ich zur zeit mit einer Merge Tabelle verbunden und überlege was aus sicher der Geschwindigkeit besser ist.
Was ist eine "Merge Tabelle"? Ist das ein View?
Die Merge Tabelle oder ein view mit SELECT AS... tabelle1 UNION tabellehistory
Views auf zwei identische Tabellen sind nicht gut.
Das Problem ist das manche Abfragen nur den aktuellen Datensatz brauchen, den ich aus der Tabelle mit den aktuellen Datensätzen hole. Manche Abfragen erfordern aber das ich den Datensatz wähle der zur angegeben Datum gültig war
Wie oft benötigst Du historische Daten? Davon würde ich die Antwort abhängig machen. Wenn selten, dann zwei Tabellen gut, wenn oft, dann zwei Tabellen schlecht, ansonsten egal. ;)
-
Was ist eine "Merge Tabelle"? Ist das ein View?
Die Merge Tabelle ist eine Zusammenfassung mithilfe der MRG_ISAM storage engine.
Die Merge Tabelle oder ein view mit SELECT AS... tabelle1 UNION tabellehistory
Views auf zwei identische Tabellen sind nicht gut.
Verstehe ich nicht ganz kannst du das mal Bitte erklären?
Gruß Daniel
-
hi,
Verstehe ich nicht ganz
Ich hingegen verstehe ganz und gar nicht, warum du die Rückfragen nicht vollständig beantwortest.
Bspw. die, _wie oft_ auf historische Datensätze zugegriffen werden soll, ist doch eine ganz wesentliche.
gruß,
wahsaga--
/voodoo.css:
#GeorgeWBush { position:absolute; bottom:-6ft; }-
Hallo wahsaga
Die Historischen Daten werden nur aufgerufen wenn der Kunde z.bsp eine rechnung aufruft und ich nicht weiß von wann die Rechnungsadresse ist.
BSP select *..... WHERE DATE.RECH BETWEEN REUSER.DATE_FROM AND REDATE_TO
das würde beim Rechnungsaufruf passieren.
dasselbe prinzip wende ich auf andere Abfragen an z.Bsp Umsatzübersicht um Abzufragen zu welchen konditione der Umsatz gebucht wurde.
Grüße :)
-
-
Die Merge Tabelle oder ein view mit SELECT AS... tabelle1 UNION tabellehistory
Views auf zwei identische Tabellen sind nicht gut.
Verstehe ich nicht ganz kannst du das mal Bitte erklären?
Wenn Du im Datendesign mehrere Tabellen mit derselben Struktur hältst (aus welchen Gründen auch immer, Performancegründe werden hier gerne angeführt LOL) und diese in einem View wieder zusammenfasst, dann handelst Du oft (nicht immer, vgl. meine Ausführungen weiter oben ;) destruktiv, denn das Durchsuchen der Tabellen wird grob geschätzt "Anzahl der Tabellen als Faktor" langsamer.
-
-
Hi Ludger,
Views auf zwei identische Tabellen sind nicht gut.
Kann man nur bedingt so pauschal sagen. Wenn es um History geht, die im selben Format/Struktur abgelegt werden "muss", dann kann man durchaus auf folgende Mechanismen zurückgreifen:
- alles in einer Tabelle (trivial ;))
- einzelne Queries auf die richtige Tabelle (wenn man sie weiss)
- dynamische Query mit UNION von ausserhalb der DB
- Partitionierte View mit UNION über alle Tabellen (btw: MS SQL kann dahingehend optimieren, dass es dann nur aus den betroffenen Tabellen selektiert)
Auf jeden Fall sollte man die Abfragen analysieren hinsichtlich gebrauch von Indizes (auch FullText ...)
Grüsse
Frank-
Views auf zwei identische Tabellen sind nicht gut.
Kann man nur bedingt so pauschal sagen.
Letztlich kann man alles nur "bedingt so pauschal sagen". Wir wollen ja nicht in Relativismus abgleiten. ;)
Wenn es um History geht, die im selben Format/Struktur abgelegt werden "muss", dann kann man durchaus auf folgende Mechanismen zurückgreifen:
- alles in einer Tabelle (trivial ;))
Nicht ganz trivial, da wir dann Zeiger auf Datensätze in ein und derselben Tabelle verwalten, was wiederum dazu führen könnte (nicht notwendigerweise ;), dass wir rekursiven Datenzugriff pflegen.
- einzelne Queries auf die richtige Tabelle (wenn man sie weiss)
So sollte es sein.
- dynamische Query mit UNION von ausserhalb der DB
So ist es oft.
- Partitionierte View mit UNION über alle Tabellen (btw: MS SQL kann dahingehend optimieren, dass es dann nur aus den betroffenen Tabellen selektiert)
Wobei wir eben das Problem haben, dass die Indizes nicht mehr so recht wollen, also zwei Tabellen bspw. grob geschätzt doppelten Aufwand generieren.
Auf jeden Fall sollte man die Abfragen analysieren hinsichtlich gebrauch von Indizes (auch FullText ...)
Bevor man mit mehreren Tabellen kommt und der Datenhaltung meint etwas Gutes zu tun bspw..
-