das mit dem key hab ich so gelöst, dass über themenid und userid ein unique key drauf liegt. damit gehts bestens.

als nächstes soll noch das mit dem index sinnvoll gemacht werden:
es gibt 4 verschiedene arten der suche:
where userid=...
where themenid=...
where themenid=... and option1=...
where themenid=... and option2=...
Und wo ist das Problem? Such doch einfach nach den Werten!

wenn es zu größeren datenmengen kommt, wäre wohl ein index vorteilhaft.
weiß nur nicht, ob es so schlau ist, 4 indexe zu erstellen für die möglichen fälle oder ob es hierbei wirklich überflüssig ist.
danke für tipps

yo,

da mein name hier schon gefallen ist, will ich mich gleich an Rouven dranhängen....

was deine erste frage betrifft, so würde ich die spalte id aus der tabelle entfernen und gleich einen zusammengesetzten primary key über userid und themenid bilden. das ersparrt dir zusätzliche constraints, wie unique und not null. der primary key über die beiden spalten vereint diese beiden merkmale schon per definition und ist ein sehr nützlicher weg, um die datenkonsestenz sicherzustellen.

was das tuning betrifft, so ist ein index immer ein geignetes mittel, aber man sollte doch ein paar dinge beachten. leider ist das thema recht komplex und füllt leicht ganze bücher. aber ein paar kleine tips, wann ein index überhaupt erst sinn macht.

• die anzahl der datensätze, bei "kleinen" tabellen macht ein index oftmals keinen sinn, da ein full join nicht viel länger dauert als ein gesetzter index. wo genau die grenze liegt musst du einfach ausprobieren.

• eine weitere faustregel besagt, wenn die ergebnismenge 10% der gesamten datenmenge überschreitet, dann lohnt es sich nicht, einen index zu verwenden. sprich bekommst du zum beispiel als ergebnis die hälfte der tabelle zurück, macht ein index keinen sinn.

• die art der daten spielt eine rolle, sprich wie ist die kardenalität in den jeweiligen spalten. gleichen sich viele einträge, zum beispiel weil sehr oft berlin oder hamburg drinn steht, männlich oder weiblich, dann wird dir ein b-baum index nichts nützen. je nach dbms würde man dann einen binär-index einsetzen können.

du siehst, es gibt schon einige dinge zu beachten. letztlich ist es so, wie ROuven sagt, alles ausprobieren und sehen, ob ein index überhaupt benutzt wird, auch wenn er vorhanden ist und schauen, ob er zeit gewinnt.

falls du denn welche einsetzen willst, würde sich die anzahl deiner indexe auf drei beschränken lassen. einen über die userid, einen über themen und option1, den letzten über themenid und option2. entscheiden für das dbms ist die reihenfolge der indexe, sprich von links nach rechts. wenn du nur nach der themid abfragen willst, sprich ohne option1 oder option2, dann kann er trotzdem auf einen der beiden indexe zurückgreifen, weil die themid ganz links steht.

Ilja