nicht angemeldet
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