Kuno: viele Interessen speichern

Ich habe ein HTML-Formular in welches man Interessen, Sportarten, Hobbys, Charaktereigenschaften usw. eintragen kann.

Also insgesamt wären das ca. 200 verschiedene checkboxen.

Ein beispiel für den Typ: Charaktereigenschaften
"launisch, romantisch, egozentrisch, hysterisch usw."

Nun meine Frage: Wie würdet ihr das in der Datenbank unterbringen?
Für jede Eigenschaft eine eigene Spalte?

  1. Hello,

    Ich habe ein HTML-Formular in welches man Interessen, Sportarten, Hobbys, Charaktereigenschaften usw. eintragen kann.

    Nun meine Frage: Wie würdet ihr das in der Datenbank unterbringen?
    Für jede Eigenschaft eine eigene Spalte?

    Nein, für jeden Eigensschaftsvorschlag ein Datensatz, für jede Eigenschaft dann ebenfalls ein Datensatz.

    Tabelle user           Tabelle property           Tabelle property_type
        ============           ================           =====================
        id_user                id_property                id_property_type
        -------                -----------                ----------------
        vorname                id_user                    name
        name                   id_property_type           description
        plz                                               active
        .....

    So kann man das Abfrageformular ausschließlich auf der tabelle property\_type aufbauen, nicht aktive Eigenschaften ausblenden, jederzeit Eigenschaften hinzufügen oder wegnehmen...

    Das Erbenis der Abfrage landet dann in der Tabelle property mit der passenden User-ID.

    So könnte man auch Historie betreiben, wenn ein User seine Eigenschaften ändern will.

    Ein harzliches Glückauf

    Tom vom Berg

    --
    Nur selber lernen macht schlau
    http://bergpost.annerschbarrich.de
    1. Verstehe!
      Aber das wäre ja dann ein ziemlich komplexes Statement, wenn ich nämlich alle User ausgeben will, die mit 150 Eigenschaften übereinstimmen. Dann muss ich für jede Eigenschaft mindestens 2 Joins machen.
      Ist das vorgehen so üblich?
      Ich finde die Idee im prinzip nicht schlecht. Ich bin blos über die vielen Joins leicht schockiert :D

      1. Mahlzeit,

        Aber das wäre ja dann ein ziemlich komplexes Statement, wenn ich nämlich alle User ausgeben will, die mit 150 Eigenschaften übereinstimmen. Dann muss ich für jede Eigenschaft mindestens 2 Joins machen.

        In welcher Form würdest Du die denn ausgeben wollen? Eine Tabelle mit n Zeilen (für jeden User eine) und 150 Spalten? Meinst Du nicht, dass das "leicht" unübersichtlich werden könnte?

        Ist das vorgehen so üblich?

        Ja. Nennt man "Normalisierung".

        Ich finde die Idee im prinzip nicht schlecht. Ich bin blos über die vielen Joins leicht schockiert :D

        Das sind deutsche Drogenbeauftragte auch oft ... ;-)

        MfG,
        EKKi

        --
        sh:( fo:| ch:? rl:( br:> n4:~ ie:% mo:} va:) de:] zu:) fl:{ ss:) ls:& js:|
        1. Hello,

          Ich finde die Idee im prinzip nicht schlecht. Ich bin blos über die vielen Joins leicht schockiert :D

          Das sind deutsche Drogenbeauftragte auch oft ... ;-)

          Hey, hey! Die Dinger heißen "Joints".

          @ Kuno: Wie würdest Du denn sonst Übereinstimmungen feststellen?

          Ein harzliches Glückauf

          Tom vom Berg

          --
          Nur selber lernen macht schlau
          http://bergpost.annerschbarrich.de
        2. yo,

          Ist das vorgehen so üblich?

          Ja. Nennt man "Normalisierung".

          mit normalisierung hat das nur bedingt zu tun, da die 150 eigenschaften mit sicherheit nicht vom gleichen typ sein werden. ich will Toms vorschlag alles mit einer beziehungstabelle abzudecken widersprechen. eine tabelle mit vielen spalten ist durchaus ein gehbarer weg und den würde ich in seinem falle auch vorziehen.

          wie gesagt handelt es sich bei den meisten eigenschaften nicht um wiederholungsspalten, welche die erste normalform (atomarität) verletzen würden, sondern um eigenschaften von ganz unterschiedlichen typ.

          Ilja

          1. Tach.

            ich will Toms vorschlag alles mit einer beziehungstabelle abzudecken widersprechen. eine tabelle mit vielen spalten ist durchaus ein gehbarer weg und den würde ich in seinem falle auch vorziehen.

            Das bringt im Gegensatz zu Toms Vorschlag jedoch den Nachteil mit sich, daß das Ergänzen neuer "Charaktereigenschaften" nicht ohne Änderungen an der Tabellenstruktur möglich ist. Oder hattest Du doch ein anderes Modell vor Augen?

            --
            Once is a mistake, twice is Jazz.
            1. yo,

              Das bringt im Gegensatz zu Toms Vorschlag jedoch den Nachteil mit sich, daß das Ergänzen neuer "Charaktereigenschaften" nicht ohne Änderungen an der Tabellenstruktur möglich ist. Oder hattest Du doch ein anderes Modell vor Augen?

              ob das ein nachteil ist sei mal dahin gestellt. es liegt in der natur der sache, dass man mit einem datenbank-modell den status quo darstellt. verändert sich dieser zustand, muss ich auch das daten-modell verändern. aber dann kann ich es richtig machen, dem neuen atrribute seine ganz eigenen eigenschaften geben, vom datentyp, domäne, NULL eigenschaft, etc.

              bei datenmodellierung kommt es meiner meinung nach auf einen wichtigen punkt drauf an, um den sich alles dreht: -> kontrolle <-
              und wenn ich nun verschiedene attribute in eine spalte packe, dann verliere ich viel von dieser kontrolle. und das würde ich nicht als vorteil ansehen.

              es gibt für mich eigentlich nur eine situation, wann ich davon abweichen würde, wenn das datenbank-modell sich in zu kurzen abständen immer wieder verändert, also sehr dynamisch ist. davon war hier aber nicht die rede, sondern eben nur von vielen attributen.

              Ilja