Tabellenübergreifender Index

[haentschman]

...in Verbindung mit kleineren Ergebnismengen (nur das holen was wirklich gebraucht wird)

Zitat:

Wenn sich das so extrem auf die Performance niederschlägt, muss etwas faul sein.

nicht immer die Fehler nur bei anderen suchen.

[Sir Rufo]

Ansonsten muss eine Tabelle erstellt werden, die alle Ausgabefelder (und die IDs) beinhaltet und mittels Trigger gefüllt wird.
In dieser Tabelle kann dann der Index entsprechend den Sortierkriterien angepasst werden.

Habe das mal spaßeshalber mit MySQL durchgespielt und die Antwortzeiten liegen beim JOIN-Select bei ca. 1.5 Sekunden und mit der Hilfstabelle bei 0.15 Sekunden.

[xZise]

Wie verhält sich denn die Sortierung, wenn du es manuell machst?

Und eine Begründung könnte sein: Bei einer Sortierung geht Quicksort bei mehreren aber nur Mergesort (es war doch so, dass man bei order by die Sortierpriorität einstellte oder? Zuerst nach A dann darin alle nach B sortieren).

MfG
Fabian

[Sir Rufo]

Die Änderung Sortierpriorität ergab bei MySQL keine anderen Zeitwerte.
Auch ein Index auf musik.titel und/oder interpret.name brachte da nix.

Grund: MySQL legte die Abfrage in eine temp. Tabelle (bei 120000 Einträgen in Musik wurde die auch noch auf die Platte ausgelagert) und dann sortiert.
Die Sortierung nimmt dann ca. 60-70% der gesamten Abfragezeit in Anspruch.

Die zusammengeführte und über Trigger/Foreign-Key aktualisierte Tabelle mit den Ausgabewerten und natürlich den passenden Indizes für die gewünschten Sortierungen (IDX1=name,titel; IDX2=titel,name) ergibt trotz der 120000 Datensätze ein sehr schnelles Ergebnis.

Ist zwar etwas Daten-Overhead aber meines Wissen nicht anders zu lösen, wenn es auf absolute Performance ankommt.

[idefix2]

Zitat:

Vielleicht wäre es eine Option das Feld nur für die Ergebnismenge und nicht für die gesamte Tabelle berechnen zu lassen

Zitat:

in Verbindung mit kleineren Ergebnismengen (nur das holen was wirklich gebraucht wird)

Kleinere Ergebnismengen bekomme ich durch Angabe einer rows Klausel (entspricht Limit in mssql). Leider beschleunigt das den Vorgang nicht wesentlich.

Dank des Hinweises von DeddyH bin jetzt draufgekommen, dass man Indizes seit Firebird 2 doch auch nach Fremdtabellen berechnen kann (über computed by an Stelle einer Spaltenangabe). Allerdings beschleunigt das den Vorgang auch nicht nennenswert, obwohl ich nur die ersten 20 abrufe und ein Index vorhanden ist, geht Firebird über die ganze Tabelle.

Zitat:

nicht immer die Fehler nur bei anderen suchen.

Nicht aus dem Zusammenhang gerissen zitieren, würde ich sagen. Ich habe im nächsten Satz geschrieben:
Wobei ich eher annehme, dass es dafür eine Lösung gibt, und dass ich nur nicht weiss, wie sie aussieht.

Zitat:

Ansonsten muss eine Tabelle erstellt werden, die alle Ausgabefelder (und die IDs) beinhaltet und mittels Trigger gefüllt wird.

Das verstehe ich jetzt nicht. Welcher Trigger (ich meine auf welches Ereignis hin)? Meinst Du eine temporäre Tabelle, die Du vor der Abfrage füllst, oder führst Du eine Tabelle permanent parallel mit? - da wäre eine trigger-befüllte Shadow-Spalte InterpretName statt der berechneten Spalte in der Tabelle Musik noch billiger. So geht es natürlich und bringt eine akzeptable Performance, ist aber meines Erachtens extrem "unschön".

[sx2008]

Zitat von idefix2:

... einen Index anzulegen, der aus Spalten in mehreren Tabellen besteht

Ein Index ist immer an eine bestimmte Tabelle gebunden.
Oder wenn man es verallgemeinert: ein Index ist immer an ein Recordset gebunden.

Bei manchen DBMS (z.B. MS SQL Server) ist es auch möglich Indexe auf Views zu legen.
Damit kann man einen Index als Verbund aus zwei oder mehr Felder aus verschiedenen Tabellen aufbauen.

Rein theoretisch könnte man sich vorstellen, Indexe tabellenübergreifend zu erstellen.
Aber man braucht dazu nicht nur die Tabellennamen sondern auch die relationale Beziehung der Tabellen.

Hier mal der Versuch, diesen Index als SQL auszudrücken:

Code:

CREATE INDEX Test (TabelleA.Feld1, TabelleB.Feld2) TabelleA INNER JOIN TabelleB ON TabelleA.PKFeldA=TabelleB.PKFeldB