Theoretische Frage zu Indizes

[*Markus]

Hallo,

für eine Webapplikation muss eine sehr effiziente Suche durch Indizes implementiert werden.
Im Datenmodell habe ich die Daten nach 3. Normalform in Look-Up-Tabellen organisiert. Das heißt, dass im Prinzip immer nur die Ziffer, die ohnehin der Primärschlüssel ist, als Index vorhanden ist, und diese Ziffer auch im Endeffekt bei der Suchabfrage selektiert wird.
Die zu implementierende Suche der Webapplikation wird aber aus vielen Einzeltabellen die Daten zusammenglauben, d.h zB

Aus Tabelle A den Eintrag 3
Aus Tabelle B den Eintrag 2
Aus Tabelle C den Eintrag 7
Aus Tabelle D den Eintrag 5

Jetzt meine Frage dazu:
Ist die Suche so eigentlich effizient, wenn die Indizes Tabelle für Tabelle gesetzt sind (wie sie aufgrund des PK ohnehin sind), oder wäre es noch effizienter, wenn ich einen Index so anlege, dass ich sage, dass "Index XYZ aus PK / TabA, PK / TabB, PK / TabB, PK / TabC" besteht, also ein zusammengesetzter Index aus den Primärschlüsseln von 4 Einzeltabellen sozusagen?
Falls dem so ist, wie verhält sich das DBMS, wenn ich irgendwann nur doch nach 3 Werten dieser 4 aus dem zusammengesetzten Index suchen muss?
Geht das DBMS dann so vor, dass es erst wieder die Einzelindizes abfragt, oder nimmt das DBMS trotzdem den zusammengesetzten Index, da ja hier bereits 3 der 4 Werte "zusammen gespeichert" sind?

Markus

[Vinzenz Mai]

Hallo,

Falls dem so ist, wie verhält sich das DBMS, wenn ich irgendwann nur doch nach 3 Werten dieser 4 aus dem zusammengesetzten Index suchen muss?

das DBMS verhält sich so, wie sich das DBMS verhält.

Sprich: sowas ist spezifisch für das jeweilige DBMS, vielleicht sogar spezifisch für unterschiedliche Storage Engines (siehe MySQL) und hoffentlich der jeweiligen Dokumentation zu entnehmen.

Freundliche Grüße

Vinzenz

[Ilja]

yo,

Im Datenmodell habe ich die Daten nach 3. Normalform in Look-Up-Tabellen organisiert.

ich hatte hier neulich schon mal eine diskusion bezüglich Look-Up Tabellen. sicherlich muss jeder selbst wissen, wie er seine daten modelliert. aber gerade was Look-Up Tabellen betrifft, wird meiner meniung nach immer wieder ein fehler gemacht. aber ich frage noch mal nach, wie sehen den diese bezüglich deines designs aus ?

Das heißt, dass im Prinzip immer nur die Ziffer, die ohnehin der Primärschlüssel ist, als Index vorhanden ist, und diese Ziffer auch im Endeffekt bei der Suchabfrage selektiert wird.

das halte ich für kritisch. ich würde grundsätzlich niemals, irgendwelche fachlichkeit in einem PK bringen. das kann zu probleme führen, diem an heute noch nicht absieht. benutze einfach immer einen künstlichen schlüssel und gut ist.

oder wäre es noch effizienter, wenn ich einen Index so anlege, dass ich sage, dass "Index XYZ aus PK / TabA, PK / TabB, PK / TabB, PK / TabC" besteht, also ein zusammengesetzter Index aus den Primärschlüsseln von 4 Einzeltabellen sozusagen?

habe ich eine entwicklung verpasst, du kannst einen zusammengesetzen index aus verschiedenen tabellen erzeugen ? so recht will ich mir das nicht vorstellen....

Ilja

[Andres Freund]

Hi,

das halte ich für kritisch. ich würde grundsätzlich niemals, irgendwelche fachlichkeit in einem PK bringen. das kann zu probleme führen, diem an heute noch nicht absieht. benutze einfach immer einen künstlichen schlüssel und gut ist.

Das ist eine sehr umstrittenes Thema ;-)

oder wäre es noch effizienter, wenn ich einen Index so anlege, dass ich sage, dass "Index XYZ aus PK / TabA, PK / TabB, PK / TabB, PK / TabC" besteht, also ein zusammengesetzter Index aus den Primärschlüsseln von 4 Einzeltabellen sozusagen?
habe ich eine entwicklung verpasst, du kannst einen zusammengesetzen index aus verschiedenen tabellen erzeugen ? so recht will ich mir das nicht vorstellen....

Ich nehme an, er hat eine Tabelle in der er suchen möchte, die foreign keys zu den 4 Lookup Tabellen enthällt.

Grüße,
Andres Freund

[Ilja]

yo,

das halte ich für kritisch. ich würde grundsätzlich niemals, irgendwelche fachlichkeit in einem PK bringen. das kann zu probleme führen, diem an heute noch nicht absieht. benutze einfach immer einen künstlichen schlüssel und gut ist.
Das ist eine sehr umstrittenes Thema ;-)

nun, ich für meinen fall finde, da gibt es wenig zu streiten. ich habe bisher noch keinen nachteil von künstlichen schlüseln kennengelernt, aber nachteile von sprechenden schlüsseln. aber sicherlich ist es nur meine meinung und man kann darüber streiten, wenn man will, muss man aber nicht. ;-)

oder wäre es noch effizienter, wenn ich einen Index so anlege, dass ich sage, dass "Index XYZ aus PK / TabA, PK / TabB, PK / TabB, PK / TabC" besteht, also ein zusammengesetzter Index aus den Primärschlüsseln von 4 Einzeltabellen sozusagen?
habe ich eine entwicklung verpasst, du kannst einen zusammengesetzen index aus verschiedenen tabellen erzeugen ? so recht will ich mir das nicht vorstellen....
Ich nehme an, er hat eine Tabelle in der er suchen möchte, die foreign keys zu den 4 Lookup Tabellen enthällt.

das habe ich auch erst gedacht, aber er hat recht explizit die verschiedenen tabellennamen angegeben, nämliche die PK aus TabA, TabB.....

Ilja

[Andres Freund]

Hi,

das halte ich für kritisch. ich würde grundsätzlich niemals, irgendwelche fachlichkeit in einem PK bringen. das kann zu probleme führen, diem an heute noch nicht absieht. benutze einfach immer einen künstlichen schlüssel und gut ist.
Das ist eine sehr umstrittenes Thema ;-)
nun, ich für meinen fall finde, da gibt es wenig zu streiten. ich habe bisher noch keinen nachteil von künstlichen schlüseln kennengelernt, aber nachteile von sprechenden schlüsseln. aber sicherlich ist es nur meine meinung und man kann darüber streiten, wenn man will, muss man aber nicht. ;-)

Wie wäre es mit wesentlich mehr Joins wenn man eigentlich nur den "Wert" des PK braucht? So teuer wie joins sind, kann das durchaus signifikant sein (Insbesondere wenn die referenzierten Tupel sehr groß sind).

Nicht falsch verstehen - ich bin prinzipiell auch ein Freund (Nein, Ben, kein Kommentar) von Surrogate Keys. Aber imho sollte man es pragmatisch sehen.

oder wäre es noch effizienter, wenn ich einen Index so anlege, dass ich sage, dass "Index XYZ aus PK / TabA, PK / TabB, PK / TabB, PK / TabC" besteht, also ein zusammengesetzter Index aus den Primärschlüsseln von 4 Einzeltabellen sozusagen?
habe ich eine entwicklung verpasst, du kannst einen zusammengesetzen index aus verschiedenen tabellen erzeugen ? so recht will ich mir das nicht vorstellen....
Ich nehme an, er hat eine Tabelle in der er suchen möchte, die foreign keys zu den 4 Lookup Tabellen enthällt.
das habe ich auch erst gedacht, aber er hat recht explizit die verschiedenen tabellennamen angegeben, nämliche die PK aus TabA, TabB.....

Ich hoffe einfach, dass du ihn falsch verstehst ;-)

Grüße,
Andres Freund

[Ilja]

yo,

Wie wäre es mit wesentlich mehr Joins wenn man eigentlich nur den "Wert" des PK braucht? So teuer wie joins sind, kann das durchaus signifikant sein (Insbesondere wenn die referenzierten Tupel sehr groß sind).

denormalisierung aus performancegründen ist durchaus ein thema, aber ich bräuchste dafür keine sprechenden schlüssel und vor allem, ich mache es dann ganz bewußt. und bei einem dbms wie oracle, habe ich andere möglichkeiten wie zum beispiel materilized views oder andere features, um die datenbank zu optimieren.

Nicht falsch verstehen - ich bin prinzipiell auch ein Freund (Nein, Ben, kein Kommentar) von Surrogate Keys. Aber imho sollte man es pragmatisch sehen.

pragmatisch gesehen habe ich noch keine vorteile davon gesehen. das heisst nicht, dass es keine gibt, vielleicht hätte ich es so ausdrücken sollen.

Ilja

[*Markus]

Hallo,

ich hatte hier neulich schon mal eine diskusion bezüglich Look-Up Tabellen. sicherlich muss jeder selbst wissen, wie er seine daten modelliert. aber gerade was Look-Up Tabellen betrifft, wird meiner meniung nach immer wieder ein fehler gemacht. aber ich frage noch mal nach, wie sehen den diese bezüglich deines designs aus ?

ja, wir hatten das Vergnügen. Ich habe auch gehofft, dass du hier wieder antwortest. Es ging auch um die Mehrsprachigkeit. Und es ist sogar das selbe Tabellenmodell, über das wir damals sprachen.
Wie auch immer, es ist jetzt fertig. Ich habe versucht, mir deine Tipps einzuverleiben, aber ich sah ehrlich gesagt für mein Modell keine Vorteile darin.
Ich weiß allerdings, was dein Anliegen dabei ist.
Jedenfalls kann es bei mir nicht vorkommen, dass PK-Werte plötzlich andere Bedeutungen haben, da beim eventuellen Hinzufügen eines Wertes in der Lookup-Tabelle - was höchstwahrscheinlich nicht vorkommt, da das Projekt relativ genau durchgeplant ist - diese Werte einfach "unten" drangehängt werden. Dann gibt es eben statt den Werten 1 - 6 von nun an die Werte 1 - 7.
Was dieses Design noch begünstigt ist die Mehrsprachigkeit.
Ich kann jetzt so vorgehen:

TabA
-----------------
haarfarbe_id (PK)
-----------------
haarfarbe_de
haarfarbe_en
haarfarbe_es
-----------------

ich kann beliebige Sprachen für die Haarfarbe zB 3 hinzufügen. Und die Beudeutung bleibt somit immer gleich (3 könnte zB blond sein)
Wie gesagt, unsere Diskussion hat mich zwar zum Nachdenken gebracht, aber ich hielt es letztendlich nicht für sinnvoll, die Haarfarbe direkt als Key zu definieren, v.a. aufgrund der Mehrsprachigkeit.
Es kann natürlich auch sein, dass mir das ganze vielleicht zu hoch ist und du eventuell doch noch etwas anderes meinst, woran ich nicht dachte.

Markus

[Andres Freund]

Hi,

Hallo,

für eine Webapplikation muss eine sehr effiziente Suche durch Indizes implementiert werden.
Im Datenmodell habe ich die Daten nach 3. Normalform in Look-Up-Tabellen organisiert. Das heißt, dass im Prinzip immer nur die Ziffer, die ohnehin der Primärschlüssel ist, als Index vorhanden ist, und diese Ziffer auch im Endeffekt bei der Suchabfrage selektiert wird.

1. Normalformen haben nicht direkt etwas mit Lookup Tabellen zu tun.
2. Normalformen haben nichts mit Indices zu tun
3. Normalform bedeutet auf keinen Fall, dass man nur nach Primärschlüsseln suchen darf.

Vielleicht schaust du dir nocheinmal genauer an, wie Normalformen genau definiert sind, und wieso sie dies sind (Überhaupt nicht böse gemeint - es ist nicht sonderlich einfach!)

Die zu implementierende Suche der Webapplikation wird aber aus vielen Einzeltabellen die Daten zusammenglauben, d.h zB

Aus Tabelle A den Eintrag 3
Aus Tabelle B den Eintrag 2
Aus Tabelle C den Eintrag 7
Aus Tabelle D den Eintrag 5

Habe ich es richtig verstanden, dass du eine Tabelle mit den Daten hast, die Foreign Keys zu A,B,C,D enthält, und du nach diesen suchen möchtest?

Jetzt meine Frage dazu:
Ist die Suche so eigentlich effizient, wenn die Indizes Tabelle für Tabelle gesetzt sind (wie sie aufgrund des PK ohnehin sind), oder wäre es noch effizienter, wenn ich einen Index so anlege, dass ich sage, dass "Index XYZ aus PK / TabA, PK / TabB, PK / TabB, PK / TabC" besteht, also ein zusammengesetzter Index aus den Primärschlüsseln von 4 Einzeltabellen sozusagen?
Falls dem so ist, wie verhält sich das DBMS, wenn ich irgendwann nur doch nach 3 Werten dieser 4 aus dem zusammengesetzten Index suchen muss?
Geht das DBMS dann so vor, dass es erst wieder die Einzelindizes abfragt, oder nimmt das DBMS trotzdem den zusammengesetzten Index, da ja hier bereits 3 der 4 Werte "zusammen gespeichert" sind?

Alle diese Fragen kann man nicht allgemein beantworten - sie sind abhängig vom jeweiligen Datenbanksystem.

Welches verwendest du denn?

Grüße,
Andres Freund

[*Markus]

Hallo,

3. Normalform bedeutet auf keinen Fall, dass man nur nach Primärschlüsseln suchen darf.

Das weiß ich natürlich. Es ergibt sich aber in meinem Fall so.

Vielleicht schaust du dir nocheinmal genauer an, wie Normalformen genau definiert sind, und wieso sie dies sind (Überhaupt nicht böse gemeint - es ist nicht sonderlich einfach!)

Davon kann ich ein Liedchen singen :)

Die zu implementierende Suche der Webapplikation wird aber aus vielen Einzeltabellen die Daten zusammenglauben, d.h zB

Aus Tabelle A den Eintrag 3
Aus Tabelle B den Eintrag 2
Aus Tabelle C den Eintrag 7
Aus Tabelle D den Eintrag 5
Habe ich es richtig verstanden, dass du eine Tabelle mit den Daten hast, die Foreign Keys zu A,B,C,D enthält, und du nach diesen suchen möchtest?

Nein sorry, ich glaube auch, dass ich einen Denkfehler gemacht habe. Ich dachte, man könne einen Index anlegen, der von verschiedenen Tabellen Werte "verbindet", so etwas wie ein "hartkodierter Join" wenn man so will.
Ich hatte nämlich die ganze Zeit den Gedanken im Kopf, dass ein Index ja im Prinzip eine Tabelle mit Referenzen ist.
Da das wahrscheinlich sowieso so nicht funktioniert, hätte sich meine Frage sowieso erübrigt, außer, ich wisst vielleicht etwas, das ich nicht weiß.

Jetzt meine Frage dazu:
Ist die Suche so eigentlich effizient, wenn die Indizes Tabelle für Tabelle gesetzt sind (wie sie aufgrund des PK ohnehin sind), oder wäre es noch effizienter, wenn ich einen Index so anlege, dass ich sage, dass "Index XYZ aus PK / TabA, PK / TabB, PK / TabB, PK / TabC" besteht, also ein zusammengesetzter Index aus den Primärschlüsseln von 4 Einzeltabellen sozusagen?
Falls dem so ist, wie verhält sich das DBMS, wenn ich irgendwann nur doch nach 3 Werten dieser 4 aus dem zusammengesetzten Index suchen muss?
Geht das DBMS dann so vor, dass es erst wieder die Einzelindizes abfragt, oder nimmt das DBMS trotzdem den zusammengesetzten Index, da ja hier bereits 3 der 4 Werte "zusammen gespeichert" sind?
Alle diese Fragen kann man nicht allgemein beantworten - sie sind abhängig vom jeweiligen Datenbanksystem.

Welches verwendest du denn?

Ich vergaß zu erwähnen. Ich verwende PostgreSQL.

Markus

[Andres Freund]

Moin,

Nein sorry, ich glaube auch, dass ich einen Denkfehler gemacht habe. Ich dachte, man könne einen Index anlegen, der von verschiedenen Tabellen Werte "verbindet", so etwas wie ein "hartkodierter Join" wenn man so will.
Ich hatte nämlich die ganze Zeit den Gedanken im Kopf, dass ein Index ja im Prinzip eine Tabelle mit Referenzen ist.
Da das wahrscheinlich sowieso so nicht funktioniert, hätte sich meine Frage sowieso erübrigt, außer, ich wisst vielleicht etwas, das ich nicht weiß.

Zeichne doch irgendwo mal dein komplettes Schema auf - bzw. poste deine CREATE TABLE statements - "pg_dump --schema-only" hilft dir.

So ist das alles gerade nur herumgerate.

Grüße,
Andres Freund

[*Markus]

Hallo,

Zeichne doch irgendwo mal dein komplettes Schema auf - bzw. poste deine CREATE TABLE statements - "pg_dump --schema-only" hilft dir.

ich habe einen Teil des Tabellenmodells ausgeschnitten:

Auf den PKs wie haarfarbe, haarstil ist aufgrund des PKs ja ein Index gelegt. Hat dieser Index jetzt einen Geschwindigkeitsvorteil für die FKs in "Profil", wenn ich daraus etwas selektiere?
Angenommen ich würde oft nach Haarstil, Haar, und Haarfarbe in "Profil" suchen wollen, ist ein zusätzlicher Index über alle 3 FKs zu legen, oder genügt hier der Index, der ja schon bei genau diesen Attributen als PK angelegt wurde?
Falls ein zusätzlicher Index angelegt werden soll, und angenommen ich würde über 5 (zB augenfarbe, profilstatus, haarstil, geschlecht, herkunftsland) dieser FKs einen Index legen, aber irgendwann nur nach 3 dieser 5 Werte suchen wollen, (zB augenfarbe, profilstatus, geschlecht) ist es dann genauso schnell?

Markus

[Ilja]

yo,

ich schreibe mal hier weiter dann müssen wir nicht an zwei stellen schauen...

grundsätzlich ist es so, dass es nicht das eine ideal daten-design gibt. das liegt zum grossen teil daran, dass ein daten-design statisch ist und man nicht in die zukunft schauen kann. es im prinzip immer ein abwägen der vorteile und der nachteile. insofern gibt es viele gehbare wege und bietet nährstoff für zahlreiche diskussionen. man muss sich halt dann für einen weg entscheiden. bei der suche nach dem individuellen design sind allerdings aussagen wie, "das design steht schon fest" und "kommt mit grosser wahrscheinlichkeit nicht vor" ein wenig problematisch.

wie auch immer, ich hätte vermutlich die eigenschaften haarfarbe nicht ausgelagert, auch nicht bei einer mehrsprachigkeit, wobei ich gestehen muss, mit daten-design für eine mehrsprachigkeit noch wenig zu tun hatte. ich hätte in der "stammtabelle" eine standartsprache ausgewählt, z.b. englisch, und je nach länderkennung mit einer unterabfrage die entsprechende sprache geholt. ich habe damit auch eine art trennung von funktionalität und design, bzw. ausgabe. nun aber was deine performance angeht.

Angenommen ich würde oft nach Haarstil, Haar, und Haarfarbe in "Profil" suchen wollen, ist ein zusätzlicher Index über alle 3 FKs zu legen, oder genügt hier der Index, der ja schon bei genau diesen Attributen als PK angelegt wurde?

da scheint mir noch ein verständnisproblem von deiner seite vorzuliegen. ein PK ist grundsätzlich immer indiziert. allerdings reicht dies nicht aus, wenn du einen join bildest. PK und FK bilden ja immer ein schlüsselpaar. insofern brauchst du auch auf der FK seite entsprechende indexe. pauschlaf kann man sagen, FK sind schonm al gute kandidaten für indexe.

ob man nun auch zusammengesetzt indexe insetzt, das hängt stark von den abfragen ab. sie bieten vorteile, aber auch nachteile. mal verallgemeinert gesagt, indexe bieten vorteile beim auslesen der daten, nidexe sind nachteilig beim verändern (insert, update, delete) von daten, da diese ja gleich vom dbms mitgepflegt werden müssen. auch hier gilt wieder das prüfen, ob indexe überhaupt benutzt werde und dann, ob es die mehrkosten wert ist.

bei tuning ist eines ganz wichtig, man braucht immer die komplette und exakte anweisung inklusive dem ausführungsplan, um entscheidungen treffen zu können. sicherlich kan man auch eni paar allgemeingültige aussagen treffen, aber an ende zählt nur trial on error.

Ilja

[*Markus]

Hallo,

wie auch immer, ich hätte vermutlich die eigenschaften haarfarbe nicht ausgelagert, auch nicht bei einer mehrsprachigkeit, wobei ich gestehen muss, mit daten-design für eine mehrsprachigkeit noch wenig zu tun hatte. ich hätte in der "stammtabelle" eine standardsprache ausgewählt, z.b. englisch, und je nach länderkennung mit einer unterabfrage die entsprechende sprache geholt. ich habe damit auch eine art trennung von funktionalität und design, bzw. ausgabe. nun aber was deine performance angeht.

Ich hätte es auch so gemacht, wenn ich keine Mehrsprachigkeit hätte. Je nachdem, welche Sprache ausgewählt ist, also zB de für Deutsch, joine ich zum Beispiel einfach die Nummer 3 für blond aus "Profil" mit der Tabelle Haarfarbe und selektiere "haarfarbe_de". Mit anderen Worten, das Sprachkürzel (de, en, etc..) wird immer dem Attributnamen der Tabelle vor dem Selektieren drangehängt. Zumindest plane ich es so zu machen.

Angenommen ich würde oft nach Haarstil, Haar, und Haarfarbe in "Profil" suchen wollen, ist ein zusätzlicher Index über alle 3 FKs zu legen, oder genügt hier der Index, der ja schon bei genau diesen Attributen als PK angelegt wurde?

da scheint mir noch ein verständnisproblem von deiner seite vorzuliegen. ein PK ist grundsätzlich immer indiziert. allerdings reicht dies nicht aus, wenn du einen join bildest. PK und FK bilden ja immer ein schlüsselpaar. insofern brauchst du auch auf der FK seite entsprechende indexe. pauschlaf kann man sagen, FK sind schonm al gute kandidaten für indexe.

Ok. Also das Einfügen von Werten ist bei dieser Tabelle absolut zweitrangig, da hier andauernd abgefragt werden wird, und nur selten aktualisiert oder eingefügt wird.
Wie würde ein Index auf den FK helfen, wenn ich folgende Abfrage hätte:

  
SELECT haarfarbe_de, haarstil_de  
FROM Haarfarbe  
INNER JOIN Profil  
ON Profil.haarfarbe = Haarfarbe.haarfarbe  
INNER JOIN Haarstil  
ON Profil.haarstil = Haarstil.haarstil  
WHERE profil_id = '1234567';  

Wäre es jetzt sinnvoll gewesen, wenn diese beiden FKs zwei einzelne Indizes wären, oder wäre in diesem Fall ein zusammengesetzter Index besser?
Und wenn jetzt nur die Haarfarbe selektiert werden würde, und das DBMS hätte diesen zusammengesetzten Index zur Verfügung, wäre das dann massiv schlechter, wäre es genauso gut, wie wenn ein einzelner Index auf dieses Attribut gesetzt hätte, oder wäre es besser?
Mir ist nämlich noch nicht so ganz klar, wie das DBMS hier vorgeht.

Markus

[Ilja]

yo,

Ich hätte es auch so gemacht, wenn ich keine Mehrsprachigkeit hätte.

wie gesagt, bei der mehrsprachigkeit bin ich mir selbst nicht ganz sicher, wie man das am besten angeht. vielleicht kann da ja noch jemand was mit mehr erfahrung dazu sagen. egal ob du nun deinen weg nimmst oder meinen vorschlag, mit beiden bekommst man sicherlich bei abfragen immer das gewünschte ergebnis zurück, es sind also beides gehbare wege.

SELECT haarfarbe_de, haarstil_de
FROM Haarfarbe
INNER JOIN Profil
ON Profil.haarfarbe = Haarfarbe.haarfarbe
INNER JOIN Haarstil
ON Profil.haarstil = Haarstil.haarstil
WHERE profil_id = '1234567';

  

> Wäre es jetzt sinnvoll gewesen, wenn diese beiden FKs zwei einzelne Indizes wären, oder wäre in diesem Fall ein zusammengesetzter Index besser?  
  
in diesem falle würde ich sagen bräuchtest du noch nicht mal einen index auf den FK, da du ja sowieso nur einen datensatz aus der profiltabelle mit dem PK selektierst.  
  

> Und wenn jetzt nur die Haarfarbe selektiert werden würde, und das DBMS hätte diesen zusammengesetzten Index zur Verfügung, wäre das dann massiv schlechter, wäre es genauso gut, wie wenn ein einzelner Index auf dieses Attribut gesetzt hätte, oder wäre es besser?  
  
bei den zusammengesetzten indexen kommt es auf die reihenfolge drauf an, welche indexe vorne stehen. wenn die spalte(n) im index abgefragt werden, die vorne stehen, dann kann er auch den zusammengesetzten nehmen. aber wie gesagt, immer den ausführunsplan anschauen und indexe nicht nur bezogen auf eine abfrage anlegen, sondern versuchen auf möglichst alle abzustellen.  
  
Ilja

[*Markus]

Hallo,

in diesem falle würde ich sagen bräuchtest du noch nicht mal einen index auf den FK, da du ja sowieso nur einen datensatz aus der profiltabelle mit dem PK selektierst.

Ja stimmt, war ein blödes Beispiel, aber du wusstest zum Glück ja, was ich meine.

bei den zusammengesetzten indexen kommt es auf die reihenfolge drauf an, welche indexe vorne stehen. wenn die spalte(n) im index abgefragt werden, die vorne stehen, dann kann er auch den zusammengesetzten nehmen. aber wie gesagt, immer den ausführunsplan anschauen und indexe nicht nur bezogen auf eine abfrage anlegen, sondern versuchen auf möglichst alle abzustellen.

Ok, also mit anderen Worten, es ist besser, wenn zu viele FKs als Index zusammengefasst wurden als zu wenige. Natürlich werde ich trotzdem versuchen, so gut wie möglich abzuwägen, welche Zusammensetzungen sinnvoll sind, aber ich glaube jetzt ungefähr eine Vorstellung von der ganzen Sache zu haben.

Markus

[Ilja]

yo,

Ok, also mit anderen Worten, es ist besser, wenn zu viele FKs als Index zusammengefasst wurden als zu wenige. Natürlich werde ich trotzdem versuchen, so gut wie möglich abzuwägen, welche Zusammensetzungen sinnvoll sind, aber ich glaube jetzt ungefähr eine Vorstellung von der ganzen Sache zu haben.

nein, diesen schluss sollte kann nicht ziehen. du brauchst genau die abfragen, die auf das design abgesetzt werden und musst dir dann entsprechend die indexe überlegen. und das geht immer nur zusammen mit dem ausführungsplan. das können zusammengesetzte indexe sein oder auch nicht. man kann dir ohne einen konkreten fall und ausführungsplan keinen vernüftigen tipp geben.

Ilja

[*Markus]

Hallo,

nein, diesen schluss sollte kann nicht ziehen. du brauchst genau die abfragen, die auf das design abgesetzt werden und musst dir dann entsprechend die indexe überlegen. und das geht immer nur zusammen mit dem ausführungsplan. das können zusammengesetzte indexe sein oder auch nicht. man kann dir ohne einen konkreten fall und ausführungsplan keinen vernüftigen tipp geben.

Ok, ich verstehe. Blöde Frage, aber können sich Indizes "überlappen"?
Ich meine, dass ich bei den Attributen A,B,C,D,E einmal A,B,C und einmal A,B,D,E zusammenfassen kann.

Markus

[Ilja]

yo,

Ok, ich verstehe. Blöde Frage, aber können sich Indizes "überlappen"?
Ich meine, dass ich bei den Attributen A,B,C,D,E einmal A,B,C und einmal A,B,D,E zusammenfassen kann.

du meinst, ob du einmal ein index mit den spalten A,B,C anlegen kannst und einmal einen mit A,B,D,E ? klar, sind halt zwei objekte.

Ilja