Logikproblem bei komplizierter Abfrage

[Markus]

Hallo,

ich habe hier eine (für mich) schwierige Situation. Ich will für einen Kumpel eine Partnerseite erstellen, bzw. mithelfen. Und da hab ich mir überlegt, folgendes wäre ganz lustig:

Man hat eine Frage, z. B.:

Rauchst du?

• Ja, oft.
• Gelegentlich.
• Bin Nichtraucher.

Dann beantwortet man die Frage zunächst für sich selbst, und anschließend legt man fest, wie der Traumpartner antworten würde.

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.

So... die technische Realisierung an sich ist wohl nicht so das Problem, ich komm nur über die Planung nicht hinaus (wie auch, sitze hier bei 30°C Hitze ;)).

Also ich dachte zunächst, ich lege 3 Tabellen an, eine wo generell alle Fragen und dazu die Antwortmöglichkeiten gelistet sind. 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. Abschließend wird verglichen: Selektiere alle Datensätze, wo die eigenen Angaben der anderen Benutzer mit den Traumpartner-Angaben bei einem selbst übereinstimmen und gib mir deren Benutzer-ID. Abschließend kann man dann noch nach Geschlecht und/oder Alter filtern...

Klingt ganz leicht irgendwie... aber ich krieg die nötigen Tabellen nicht aufgestellt. Kann mir vielleicht jemand nen kleinen Denkanstoß geben?

LG
Markus

[wahsaga]

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

[Ilja]

yo,

die frage ist vor allem, kann es für eine frage mehrfachantworten geben oder immer nur eine antwort. danach würde sich das design richten müssen.

Ilja

[Markus]

yo,

die frage ist vor allem, kann es für eine frage mehrfachantworten geben oder immer nur eine antwort. danach würde sich das design richten müssen.

Genau daran dachte ich auch grad - am meisten Sinn macht es wohl, wenn die *eigene* Antwort nur eine Möglichkeit zulässt, aber bei der Frage, wie der Traumpartner antworten müsste, könnte man mehrere zulassen (man ist ja möglicherweise toleranz oder es ist einem nicht so wichtig).

Lg
Markus

[wahsaga]

hi,

die frage ist vor allem, kann es für eine frage mehrfachantworten geben oder immer nur eine antwort. danach würde sich das design richten müssen.

Genau daran dachte ich auch grad - am meisten Sinn macht es wohl, wenn die *eigene* Antwort nur eine Möglichkeit zulässt, aber bei der Frage, wie der Traumpartner antworten müsste, könnte man mehrere zulassen (man ist ja möglicherweise toleranz oder es ist einem nicht so wichtig).

Ein weiterer Aspekt, den ich in meiner ersten Antwort auch nicht berücksichtigt habe, wäre dann - muss der Nutzer zu allem Angaben machen, oder reichen auch Teile aus, und der Rest würde dann als "egal" angesehen?
Dann wäre es vielleicht weniger sinnvoll, den "Default" "egal" auch überall mit abzuspeichern - dann könnte eine Normalisierung, die das ganze doch auf eine 1:N-Beziehung User:Wahlmöglichkeiten abbildet, u.U. doch vorteilhafter sein, als eine starre Struktur, die alle Möglichkeiten in Spalten nur eines Datensatzes abbildet.

gruß,
wahsaga

[Markus]

Ein weiterer Aspekt, den ich in meiner ersten Antwort auch nicht berücksichtigt habe, wäre dann - muss der Nutzer zu allem Angaben machen, oder reichen auch Teile aus, und der Rest würde dann als "egal" angesehen?
Dann wäre es vielleicht weniger sinnvoll, den "Default" "egal" auch überall mit abzuspeichern - dann könnte eine Normalisierung, die das ganze doch auf eine 1:N-Beziehung User:Wahlmöglichkeiten abbildet, u.U. doch vorteilhafter sein, als eine starre Struktur, die alle Möglichkeiten in Spalten nur eines Datensatzes abbildet.

Ja, ich hab dein Posting gelesen und hab über ein Ranking nachgedacht... aber ich denke ein starrer Vergleich ist doch sinnvoll, wenn man wie gesagt mehrere Antwortmöglichkeiten hat. 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). Stellt sich für mich nur grad die Frage (hab kaum Erfahrungen damit), wie man mehrere Antwortmöglichkeiten in einer DB-Spalte zusammenfasst? Andernfalls könnte ich natürlich mehrere Spalten machen (antwort1, antwort2, antwort3, ...) und dann jeweils abfragen, ob da was drinsteht... aber das kommt mir ziemlich amateurhaft vor, da gibts doch bestimmt was eleganteres?

Dennoch schonmal vielen Dank ;)

LG
Markus

[wahsaga]

hi,

Ja, ich hab dein Posting gelesen und hab über ein Ranking nachgedacht... aber ich denke ein starrer Vergleich ist doch sinnvoll, wenn man wie gesagt mehrere Antwortmöglichkeiten hat.

Halte ich nach wie vor nicht für sinnvoll.

Wenn es einen möglichen "Partner" gibt, mit dessen Interessen meine Wünsche in fast allen Punkten übereinstimmen, nur in einem oder zweien nicht - dann wird deine Plattform uns, wenn du wirklich nur auf absolute Übereinstimmungen vergleichst, höchstvermutlich nie zusammenbringen.
Und gerade am Anfang ist die Nutzerbasis noch nicht so groß, exakte Übereinstimmungen wird es also dann noch sehr wenige geben - und wenn dein System deshalb kaum "Treffer" zu landen in der Lage ist, dann wird es vermutlich auch in der weiteren Zukunft bei einem kleinen und äußerst überschaubaren Nutzerkreis bleiben, denn ohne "Erfolge" schafft dein System keine Anreize, es weiterzuempfehlen.

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.

Stellt sich für mich nur grad die Frage (hab kaum Erfahrungen damit), wie man mehrere Antwortmöglichkeiten in einer DB-Spalte zusammenfasst?

Muss man ja nicht - wie gerade geschrieben, eine 1:N Beziehung zwischen Nutzer und Frage-Antwort-Paaren.

(Und wenn es sich für einzelne Fragen bzw. vielleicht eher Eigenschaften eines Nutzers - Geschlecht, Nicht-/Raucher, etc. - doch anbietet, dann wie schon gesagt bspw. über Datentypen wie ENUM/SET von MySQL oder vergleichbares, die dann direkt am Nutzerdatensatz hängen können.)

Andernfalls könnte ich natürlich mehrere Spalten machen (antwort1, antwort2, antwort3, ...)

Nein, so ein System ist ziemlich unflexibel und schlecht erweiterbar.

gruß,
wahsaga

[Ilja]

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

[Ilja]

yo,

bei der tabelle traumpartner habe ich noch die spalte id als primarky key und autoincrement vergessen.

Ilja