nicht angemeldet
yo,
ok, nachdem man weiß, dass mehrfach-anworten für den traumpartner möglich sind, kann man sich an das design machen. es gibt immer mehrere möglichkeiten, wo man dann zwischen den verschiedenen vor und nachteilen abwägen muss. ich würde es erst einmal so machen:
tabelle fragen:
id int autoincrement primary key
frage varchar not null unique
tabelle antworten:
id int autoincrement primary key
antwort varchar not null unique
tabelle fragen_antworten (m:n beziehung zwischen fragen und antworten):
fragen_id int foreign key zu fragen
antworten_id int foreign key zu antworten
auf die letzte tabelle noch einen kombinierten unique constraint auf beide spalten fragen_id und antworten_id.
diese ersten drei tabellen habe ich bewußt als erster erwähnt, weil sie mehr oder weniger nur als vorlage dienen und nicht direkt mit in die auswertung einfließen werden. es dient quasi nur dazu festzuhalten, welche fragen gibt es für meinen wunschpartner und welche antworten darauf, mehr nicht. sie dient dann später bei der php umsetzung zum aufbau des fragen/antworten formulars, wobei manche fragen antworten besitzen wie von/bis oder ja/nein. man kann diese drei tabellen auch ganz weglassen und alle fragen und antworten in der php programmierung unterbringen.
jetzt kommen die tabellen, wo die wirklichen "individuellen" daten abgelget werden.
tabelle mitglieder (oder anderer passender name):
id int autoincrement primary key
name varchar not null unique
geburtsdatum not null
koerpergroesse float not null
gewicht float not null
haarfarbe varchar not null
etc.
in der tabelle (entität) mitglieder befinden neben dem üblichen attributen wie namen auch alle notwendigen daten zur auswertung der übereinstimmung als traumpartner für ein anderes mitglied wieder. man könnte bei einigen attributen, zum beispiel bei der haarfarbe wieder die vorlagen tabellen benutzen, um die entsprechenden auswahlkriterien im formular auszugeben. in diesem falle zum beispiel blond, rot, braun, etc. bei werten wie gewicht gibt es natürlich keine vorgaben.
nun wird es kniffliger, jetzt kommt die tabelle mit den werten für den wunschpartner. diese unterscheiden sich zum teil von den eigenen angaben bei der mitglieder tabelle. wie gesagt beim gewicht macht man nur eine angabe, beim wunschpartner sind es schon zwei, nämlich gewicht von/bis. mansche antworten können unbestimmbar viele elemente haben, zum beispiel die wunschhaarfarbe des partners.
man hat sicherlich verschiedene möglichkeiten, die wunschpartnerdaten festzuhalten.
Ich dachte erst, ich mach eine Tabelle für die Antworten (id, antwort) und eine für die Fragen (id, frage) und füge beides schließlich in einer Tabelle zusammen (id_frage, id_antwort).
Ja, so in etwa.
Da die Fragen natürlich für alle Nutzer die gleichen sind, können sie ohne Nutzerbezug abgelegt werden, und die Antwortmöglichkeiten ebenso - und die jeweiligen Antworten der einzelnen Nutzer dann natürlich mit, Nutzer-ID - Frage-ID - Antwort-ID.
das geht ganz so einfach nicht, weil bestimmte antworten einen wert besitzen, zum beispiel bei dem gewicht von/bis. deswegen muss die tabelle noch um eine spalte erweitert werden. ausserdem handelt es sich um eine typische n:m beziehung und nicht 1:n. das wird schon durch die fremdschlüssel der tabellen deutlich.
tabelle traumpartner:
mitglieder_id int foreign key zu mitglieder
fragen_id int foreign key zu fragen
antwort_id int foreign key zu antworten
wert varchar not null, eventuell auch float falls nur zahlen vorkommen.
Ilja