nicht angemeldet
hi,
Zum Schluss kann man eine Seite aufrufen, auf der einem Leute angezeigt werden, die zu einem passen würden. Dabei soll dann verglichen werden: Meine "Traumpartner-Antwort" mit der "Selbst-Antwort" anderer Leute. Dort, wo es die größte Übereinstimmung gibt, sollen die Leute angezeigt werden.
Da es wohl nicht immer exakte Übereinstimmungen geben wird - vermutlich sogar eher selten - wirst du dir also einen Scoring-Algorithmus überlegen müssen, der die eventuellen Übereinstimmungen irgendwie gewichtet.
Also ich dachte zunächst, ich lege 3 Tabellen an, eine wo generell alle Fragen und dazu die Antwortmöglichkeiten gelistet sind.
Kann, muss nicht.
Die Spaltentypen ENUM/SET bei MySQL könnten z.b. hier eingesetzt werden, bevor man es mit der Normalisierung übertreibt.
Dann eine Tabelle, wo die eigenen Antworten festgehalten sind: Die ID des Benutzers, die ID der Frage und die ID der gewählten antwort. Und letztlich noch eine Tabelle wo die Antworten gespeichert sind, die der Traumpartner geben würde: Wieder Benutzer-ID, Fragen-ID und Antwort-ID.
Da sehe ich nicht unbedingt zwei Tabellen, sondern eher eine.
Schließlich wirst du doch von jedem Nutzer die beide Datensätze erheben wollen - seine eigenen Eigenschaften, und was er sucht.
"Ich bin Nichtraucher, gehe gern ins Kino, ..."
"Ich suche eine(n) Nichtraucher(in), der/die gern ins Theater geht, ..."
Diese beiden Datensätze haben im großen und ganzen die gleiche Struktur - sie unterscheiden sich nur dadurch, dass ich mit dem einen mich selbst charakterisiere, und mit dem anderen das Gegenüber, welches ich finden möchte.
Dieser alleinige Unterschied der beiden Datensätze lässt sich auch in einem Kennzeichen abbilden, ob es nun die Selbstbeschreibung oder das Gesuch ist - das erfordert keine zwei getrennten Tabellen.
gruß,
wahsaga
/voodoo.css:
#GeorgeWBush { position:absolute; bottom:-6ft; }