Wie findet ihr folgendes Vorgehen. (MYSQL)

[Frido]

Moin.

Die Leute auf meiner Seite haben ein Profil das andere Mitglieder sehen können.

Es gibt verschiedene Kategorien wie zum Beispiel "Allgemeines", "Karriere", "Persönliches"

Unter diesen Kategorien gibt es verschiedene Angaben. Unter "Allgemeines" zum Beispiel: Geburtsdatum, Herkunft, Religion.

Bei manchen Angaben gibt es ein Select-Feld mit vordefinierten Optionen.
Unter Religion zum Beispiel evangelisch, katholisch, sunnitisch, schiitisch, jüdisch, buddhistisch...

Nun stekkt sich die Frage wie man das am besten in die Datenbank umsetzt.
Mein Ansatz mit Beispieleinträgen:

Tabelle user_information_category
categoryid categoryname
1          Allgemeines

Tabelle user_information_information
informationid categoryid informationname
1             1          Religion
2             1          Herkunft

Tabelle user_information_information_option
informationid optionname
1             katholisch
1             evangelisch
1             buddhistisch

user_information
userid informationid information
1      1             1
1      2             Deutschland

Meine Abfrage sähe dann so aus:

  
SELECT information, categoryname, informationname, optionname  
FROM user_information  
JOIN user_information_information ON user_information_information.informationid=user_information_information.informationid  
JOIN user_information_category ON user_information_category.categoryid = user_information_information.categoryid  
JOIN user_information_information_option ON user_information_information_option.informationid = user_information_information.informationid  
WHERE userid='1'

Wie findet ihr das Model und die Abfrage?

Gruß, Frido

[Klawischnigg]

Hi there,

Wie findet ihr das Model und die Abfrage?

völlig überdreht. Keine Daten, die nicht in einer einzigen Tabelle Platz hätten (was auch Deine Abfrage radikal vereinfachte). Die paar Referenzdaten wie Religion etc. kannst Du auch in ein Array der Programmiersprache schreiben, die Du für die Verwaltung Deiner DB verwendest...

[Frido]

Hi.

völlig überdreht. Keine Daten, die nicht in einer einzigen Tabelle Platz hätten (was auch Deine Abfrage radikal vereinfachte). Die paar Referenzdaten wie Religion etc. kannst Du auch in ein Array der Programmiersprache schreiben, die Du für die Verwaltung Deiner DB verwendest...

Dann sag mir doch bitte welche Tabellen du wegmachen würdest.
Also okay user_information_information_option kann weg.

Sonst nochwas? Die Kategorien vielleicht aber dann müsste ich später für jede Kategorie eine Abfrage machen...

Gruß,

Frido

[Klawischnigg]

Hi there,

Dann sag mir doch bitte welche Tabellen du wegmachen würdest.

Ich würde eine einzige Usertabelle mit den entsprechenden Feldern anlegen. Wenn Du Einträge in bestimmen Feldern standardisieren möchtest, musst Du halt vorher ein Array mit den entsprechenden Option anlegen. Das ist imho vertretbar bei den Daten. (zumal bei Religionen, wo nach meinem dafürhalten eigentlich eine schon zuviel ist;)

Sonst nochwas? Die Kategorien vielleicht aber dann müsste ich später für jede Kategorie eine Abfrage machen...

Wenn ich Dich richtig verstehe möchtest Du diesen Abfragen dadurch entgehen, indem Du bereits alles zusamman auflistest, oder hab ich Dich falsch verstanden?

[Frido]

Ich würde eine einzige Usertabelle mit den entsprechenden Feldern anlegen. Wenn Du Einträge in bestimmen Feldern standardisieren möchtest, musst Du halt vorher ein Array mit den entsprechenden Option anlegen. Das ist imho vertretbar bei den Daten. (zumal bei Religionen, wo nach meinem dafürhalten eigentlich eine schon zuviel ist;)

Du meinst also so?

Tabelle user_information
userid categoryname informationname information
1      Allgemeines  Herkunft        Deutschland
1      Allgemeines  Religion        Katholisch

So? Aber dann habe ich ja x - fach Allgemeines da stehen anstatt einer einfachen Zahl und x-fach Herkunft und Religion für jeeeeden User.

Wenn ich Dich richtig verstehe möchtest Du diesen Abfragen dadurch entgehen, indem Du bereits alles zusamman auflistest, oder hab ich Dich falsch verstanden?

Also es ist ein Profil
Die User können alle Angaben optional machen.
Ich weiß nicht wie ich das dann managen soll. X Abfragen machen?
ich bin total verwirrt gerade, könntest du das alles mal in pseudo code doer so schreiben?

Gruß, Frido

[Gunther]

Hi Frido!

IMHO bringst du zwei Dinge durcheinander. ;-)
Das Eine ist die Presentation deiner Daten (auf der Webseite) und das Andere ist die Speicherung der Daten (in deiner DB).

Du willst (so wie ich das hier verstehe) deine Daten 1:1 entsprechend ihrer Darstellung/ Representation auf deiner Webseite speichern.

Das ist aber weder *erforderlich*, noch *sinnvoll* (wie dir Klawischnigg bereits versucht hat zu erklären).

»» Ich würde eine einzige Usertabelle mit den entsprechenden Feldern anlegen.

Du meinst also so?

Tabelle user_information
userid categoryname informationname information
1      Allgemeines  Herkunft        Deutschland
1      Allgemeines  Religion        Katholisch

Nein, meint er nicht.
Pro User *einen* Eintrag (^= eine Zeile) und für jede (mögliche) Information ein Feld (Spalte) in deiner Tabelle.

Eine Abfrage kann dann bspw. auf per User Basis erfolgen, wobei entweder direkt alle Felder abgefragt werden, oder nur bestimmte.

Gruß Gunther

[Frido]

Hallo Gunther.

»» Tabelle user_information
»» userid categoryname informationname information
»» 1      Allgemeines  Herkunft        Deutschland
»» 1      Allgemeines  Religion        Katholisch

Nein, meint er nicht.
Pro User *einen* Eintrag (^= eine Zeile) und für jede (mögliche) Information ein Feld (Spalte) in deiner Tabelle.

Achsooo. Also:
Userid Herkunft Religion
1      Deutsch  Katholisch

Schön und gut nun habe ich aber das Problem der Datenredundanz.
Schließlich ist jede Angabe optional. Habe ich aber auch schon geschrieben.
Und deswegen dachte ich halt es wäre sinnvoller das so zu machen wie ich bisher dachte.

Gruß, Frido

[Gunther]

Hallo Frido!

»» »» Tabelle user_information
»» »» userid categoryname informationname information
»» »» 1      Allgemeines  Herkunft        Deutschland
»» »» 1      Allgemeines  Religion        Katholisch
»»
»» Nein, meint er nicht.
»» Pro User *einen* Eintrag (^= eine Zeile) und für jede (mögliche) Information ein Feld (Spalte) in deiner Tabelle.

Achsooo. Also:
Userid Herkunft Religion
1      Deutsch  Katholisch

Genau!

Schön und gut nun habe ich aber das Problem der Datenredundanz.
Schließlich ist jede Angabe optional. Habe ich aber auch schon geschrieben.
Und deswegen dachte ich halt es wäre sinnvoller das so zu machen wie ich bisher dachte.

Bei den paar Daten sehe ich da nicht unbedingt ein Problem (bin allerdings kein Fachmann auf dem Gebiet). Das "Handling" der Daten (also die benötigten Abfragen) sind aber deutlich einfacher (effizienter?). Vergleiche: http://de.wikipedia.org/wiki/Datenredundanz#Datenbanken_und_Datenstrukturen

Ich persönlich würde jedenfalls auch dem Vorschlag von Klawischnigg folgen.

Gruß Gunther

[Frido]

Bei den paar Daten sehe ich da nicht unbedingt ein Problem (bin allerdings kein Fachmann auf dem Gebiet). Das "Handling" der Daten (also die benötigten Abfragen) sind aber deutlich einfacher (effizienter?). Vergleiche: http://de.wikipedia.org/wiki/Datenredundanz#Datenbanken_und_Datenstrukturen

Um genau zu sein es sind 35 optionale Angaben!
Sprich bei 100.000 Mitgliedern wären das 3,5 Millionen Einträge in der einen Tabelle. Bei 1.000.000 Mitgliedern, 35 Millionen Einträge. Da kaum einer alle ausfüllen wird und ich sage mal 3 Frei bleiben, hätte ich 3 Millionen Einträge die NULL sind.

Ich kenne mich zu wenig aus um das beurteilen zu können!
Wie seht ihr das? Also wie sollich nun vorgehen. Ich hatte noch in ein Projekt mit einer Datenbank von 35 Spalten in einer Tabelle.

Gruß,

Frido

[Tom]

Hello,

Um genau zu sein es sind 35 optionale Angaben!

Es sind _jetzt_ 35 optionale Angaben, also Eigenschaften. Könnte sich der Umfang in absehbarer Zeit ändern? Könnten welche hinzukommen oder wegfallen?

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[Frido]

Hi.

Es sind _jetzt_ 35 optionale Angaben, also Eigenschaften. Könnte sich der Umfang in absehbarer Zeit ändern? Könnten welche hinzukommen oder wegfallen?

Vorerst nicht. Es sind halt Profilangaben. Vllt überdenkt man sie irgendwann mal oder denkt - hm das sollte man auch angeben können. Usw..

Gruß, Frido

[Tom]

Hello,

Es sind _jetzt_ 35 optionale Angaben, also Eigenschaften. Könnte sich der Umfang in absehbarer Zeit ändern? Könnten welche hinzukommen oder wegfallen?

Vorerst nicht. Es sind halt Profilangaben. Vllt überdenkt man sie irgendwann mal oder denkt - hm das sollte man auch angeben können. Usw..

Es kommt garantiert noch viel schlimmer. Irgendwann soll bestimmt zu den Eigenschaften(arten), die dem Bentuzer zugewiesen wurden, noch eine Beschreibung hinzukommen odr ein Klartext. Eigenschaften könnten nämlich auch selber wieder mehrwertig werden.

"Telefonnummer" und "eMail-Name" sind z.B. solche mehrwertigen Eigenschaften, also welche, von denen dem Hauptobjekt mehrere gleichzeitig zugewiesen werden könnten.

Und da ist dann das Konzept mit der saubere Aufteilung auf mehrere Tabellen auf jeden Fall schneller überarbeitet.

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[Frido]

Ja das stimmt schon was du sagst.

Ich habe mir mal den Spaltentyp: SET angeguckt.
Ist sowas denn von der Performance her vertretbar?

Also ich kann mir das doch so vorstellen:

Tabelle: user_information

INT     SET(name, vorname, option1, option2...)
userid information
1      frido, lin, wert1, wert2

Aber es gibt Haken, die User könnten "," einfügen bei der Trennung ihrer Interessen die sie angeben können und wie siehts aus mit Umbrüchen usw, werden escaped? Die sollen  beibehalten bleiben.

Also ich stehe jetzt echt in er Klemme zweischen

usertabelle, eigenschaftstabelle und user_eigenschafts tabelle

und einer einzelnen

usereigenschaftstabelle

Gruß, Frido

[Tom]

Hello,

Also ich kann mir das doch so vorstellen:

Tabelle: user_information

INT     SET(name, vorname, option1, option2...)
userid information
1      frido, lin, wert1, wert2

Der Datentyp "SET" ist eigentlich ein vergewaltigter String, also eine Nachschlageliste.
Du kannst seit neueren MySQL_Versionen (?? 5.x) später auch Änderungen daran vornehmen, ohne dass die vorhandenen Daten darunter leiden. Sie werden bei einer Änderung automatisch aktulisisiert.

Das hat aber zur Voraussetzung, dass man auch immer über den Datenwert zugreift, nicht übner dessen Index. Außerdem sind keine numerischen Werte für die Verwendung von SET und ENUM zulässig, wenn einem seine Daten lieb sind.

name und vorname würden nach meinem Ermessen nicht in das SET gehören, da sie wohl kaum optional sein dürften, sondern zu den mandatorischen Stammdaten des Users gehören sollten.

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[Frido]

Also von dem SET lasse ich lieber mal die Finger.

;)

[Tom]

Hello,

Also von dem SET lasse ich lieber mal die Finger.
;)

Gute Entscheidung.

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[Gunther]

Hello!

»» > Es sind _jetzt_ 35 optionale Angaben, also Eigenschaften. Könnte sich der Umfang in absehbarer Zeit ändern? Könnten welche hinzukommen oder wegfallen?
»»
»» Vorerst nicht. Es sind halt Profilangaben. Vllt überdenkt man sie irgendwann mal oder denkt - hm das sollte man auch angeben können. Usw..

Das würde ich jetzt schon tun - das mit dem Überdenken!
35!!! optionale Angaben, um sich und seine Privatsphäre im Web bloßzustellen?
Und mal ehrlich: Wen interessiert das, bzw. wer liest das? Und was noch viel wichtiger ist: Wer schreibt da was (stimmendes) rein?

Es kommt garantiert noch viel schlimmer. Irgendwann soll bestimmt zu den Eigenschaften(arten), die dem Bentuzer zugewiesen wurden, noch eine Beschreibung hinzukommen odr ein Klartext. Eigenschaften könnten nämlich auch selber wieder mehrwertig werden.

"Telefonnummer" und "eMail-Name" sind z.B. solche mehrwertigen Eigenschaften, also welche, von denen dem Hauptobjekt mehrere gleichzeitig zugewiesen werden könnten.

Ja klar, und das Feld mit dem Datum der letzten Aktivität nicht vergessen!
Die meisten Projekte werden meist gar nicht so alt, als dass sich derartige Probleme überhaupt auftun würden.

Falls doch, kann man zwecks Vereinfachung auch einfach Konventionen festlegen. Also bspw. würden imho auch eine Tel.-Nr. und eine E-Mail Addy pro User reichen.

Und da ist dann das Konzept mit der saubere Aufteilung auf mehrere Tabellen auf jeden Fall schneller überarbeitet.

Das halte ich zumindest für "fragwürdig".
Wenn ich die Aus-/ Eingabe und Abfrage so gestalte, dass sie unabhängig von der tatsächlichen Anzahl an Optionen ist, dann kann ich im Prinzip Felder in der DB anfügen, (fast) ohne irgendetwas anderes auch ändern zu müssen.

Und für den (unwahrscheinlichen - denn den gilt es im Vorfeld möglichst zu vermeiden) Fall, dass später doch noch "erweiterte" Daten mit aufgenommen werden sollen, kann man dann ggf. immer noch auf zusätzliche Tabellen zurückgreifen.

Also letztlich ist es etwa vergleichbar mit der Wahl des "richtigen" Handy-Tarifs. Wenn man sein Telefonier- (und Surfverhalten) im Vorfeld genau kennen würde, dann könnte man den "günstigsten" Tarif auswählen. Ändert sich später jedoch das angenommene Telefonier- (und Surfverhalten), dann kann er sich durchaus als "ungünstig" herausstellen. That's life!
Natürlich könnte man auch von vornherein gewisse "Abweichungen" mit einkalkulieren und dadurch ggf. einen Tarif wählen, der zwar nicht der Optimale ist, aber bei Änderungen (gegenüber der Annahme/ Voraussage/ Prognose) nicht so ungünstig ist, wie der andere Tarif.

Diese Abwägung/ Einschätzung ist das, was dem OP im Endeffekt keiner abnehmen kann.

Gruß Gunther

[Klawischnigg]

Hi there,

Um genau zu sein es sind 35 optionale Angaben!
Sprich bei 100.000 Mitgliedern wären das 3,5 Millionen Einträge in der einen Tabelle. Bei 1.000.000 Mitgliedern, 35 Millionen Einträge. Da kaum einer alle ausfüllen wird und ich sage mal 3 Frei bleiben, hätte ich 3 Millionen Einträge die NULL sind.

Es tut mir leid, wir haben immer noch ein Verständnisproblem. Was spricht dagegen, in einer Usertabelle einfach 35 Felder für Deine Optionen anzulegen?

zB:

ID Name Vorname Geb.Datum Option1 Option2 Option3...Option35

Ich kenne mich zu wenig aus um das beurteilen zu können!

Naja, ein kreuzweises Joinen wäre wirklich ein Overkill gewesen;)

Wie seht ihr das? Also wie sollich nun vorgehen. Ich hatte noch in ein Projekt mit einer Datenbank von 35 Spalten in einer Tabelle.

Ok, Du nennst es Spalten, ich nenne es Felder, je nachdem, ob man es von der Reräsentation in der Tabelle oder von einem Datensatz her betrachtet, aber nichtsdestotrotz spricht ja nichts gegen 35 Spalten, oder?

[Auge]

Hallo

»» Um genau zu sein es sind 35 optionale Angaben!
»» Sprich bei 100.000 Mitgliedern wären das 3,5 Millionen Einträge in der einen Tabelle. Bei 1.000.000 Mitgliedern, 35 Millionen Einträge. Da kaum einer alle ausfüllen wird und ich sage mal 3 Frei bleiben, hätte ich 3 Millionen Einträge die NULL sind.

Es tut mir leid, wir haben immer noch ein Verständnisproblem. Was spricht dagegen, in einer Usertabelle einfach 35 Felder für Deine Optionen anzulegen?

Wenn es an den möglichen Eigenschaften *keine* Änderungen geben soll, spricht nichts dagegen. Wenn diese Bedingung allerdings nicht zutrifft, jedoch <polemik>alles</polemik>.

Ich würde das, ob der mMn anzustrebenden Flexibilität, mit drei Tabellen erschlagen wollen.

• Benutzertabelle (wie gehabt)
• Eigenschaftentabelle (id, Eigenschaft[, evtl. Gruppe von Eigenschaften])
• Tabelle mit jeweils einer Eigenschaft pro Benutzer in einer Zeile (Benutzer_ID, Eigenschafts_ID)

Tschö, Auge

[Klawischnigg]

HI there,

Ich würde das, ob der mMn anzustrebenden Flexibilität, mit drei Tabellen erschlagen wollen.

ja, eh, ich wollt ja nur auf dem Overkill des OP ein möglichst einfaches Konzept entgegenhalten...;)

[Frido]

Hi.

*Verwirrung*

_was_ wäre nun am angebrachtesten?
35 Optionale Felder. GGf. könnte mal eine Option Hinzukommen oder Wegfallen.

[Klawischnigg]

Hi there,

*Verwirrung*

no need to worry...

35 Optionale Felder. GGf. könnte mal eine Option Hinzukommen oder Wegfallen.

Und? "ALTER TABLE ADD COLUMN option36..."

[Tom]

Hello,

35 Optionale Felder. GGf. könnte mal eine Option Hinzukommen oder Wegfallen.

Und? "ALTER TABLE ADD COLUMN option36..."

Das ist aber nur das Datendesign
Anschließend müssen alle Zugriffsfunktionen und die Frontends noch angepasst werden.
Das sollte man sich doch ersparen, indem man die Dynamik rechtzeitig in die Datenachse (Spalte) und nicht in die Satzbeschreibung (Zeile) legt.

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[Klawischnigg]

Hi there,

»» Und? "ALTER TABLE ADD COLUMN option36..."

Das ist aber nur das Datendesign
Anschließend müssen alle Zugriffsfunktionen und die Frontends noch angepasst werden.

Du gibst nicht auf, oder? ;)

Wenn man so etwas plant, dann kann man ja bei der Abfrage die Anzahl der Optionsfelder mit abfragen und die Reaktion und die Darstellung entsprechend variabel halten. (ausser natürlich, man hört auf den Komiker hier im Forum und verwendet ausser zu Testzwecken *NIE* den * bei der Abfrage;)

Das sollte man sich doch ersparen, indem man die Dynamik rechtzeitig in die Datenachse (Spalte) und nicht in die Satzbeschreibung (Zeile) legt.

Auch auf die Gefahr hin, mich zu wiederholen: Du hast ja recht! Es hängt eben von vielen Faktoren ab, wie man sich dem Problem des Originalposters nähert...;)

[Frido]

Hi.

Wenn man so etwas plant, dann kann man ja bei der Abfrage die Anzahl der Optionsfelder mit abfragen und die Reaktion und die Darstellung entsprechend variabel halten. (ausser natürlich, man hört auf den Komiker hier im Forum und verwendet ausser zu Testzwecken *NIE* den * bei der Abfrage;)

Also es ist ein größeres Projekt und es ging mir jetzt halt einfach um die Performance. Ich bin gerne bereit 10 Minuten mehr zu investieren - falls sich - ggf - irgendwann mal etwas ändern sollte an den 35 Spalten.

Also ist es schneller wenn ich in einer einfachen Abfrage auf nur 1 Tabelle zugreifen muss. Als auf 4 Tabellen mit JOINS usw.

[Klawischnigg]

Hi there,

Also ist es schneller wenn ich in einer einfachen Abfrage auf nur 1 Tabelle zugreifen muss. Als auf 4 Tabellen mit JOINS usw.

Das mit Sicherheit, auch wenn Du ausser ab einigen Millonen Datensätzen keinen Unterschied merken dürftest. Das Prinzip Geschwindigkeit gegen Speicherbedarf gilt noch immer...

[Tom]

Hello,

Auch auf die Gefahr hin, mich zu wiederholen: Du hast ja recht! Es hängt eben von vielen Faktoren ab, wie man sich dem Problem des Originalposters nähert...;)

Eine schnelle, schmutzige Lösung für geizige Kunden führt dann eben zu baldigem Nachbesserungsbedarf,
eine gute und durchdachte Lösung eventuell zum Verlust des Auftrages.

In sofern gebe ich Dir auch Recht. Man sieht es ja an M$-Programmen. Da werden dieselben fehler immer wieder in anderer Verpackung verkauft. Und Scheiß auf die Daten der Kunden, der Datenrettungsservice will schlöießlich auch leben. Diese Vorgehensweise kann nicht falsch sein, denn M$ ist bisher noch nicht pleite, ganz im Gegenteil!

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[Frido]

Hi.

Es tut mir leid, wir haben immer noch ein Verständnisproblem. Was spricht dagegen, in einer Usertabelle einfach 35 Felder für Deine Optionen anzulegen?

Im Prinzip garnichts, ich dachte nur man sollte leere Spalten vermeiden.
Sprich normalisierte Tabellen verwenden.

Ok, Du nennst es Spalten, ich nenne es Felder, je nachdem, ob man es von der Reräsentation in der Tabelle oder von einem Datensatz her betrachtet, aber nichtsdestotrotz spricht ja nichts gegen 35 Spalten, oder?

Hm dachte halt das das die Abfrage sehr lahm machen wärde bei einer großen Tabelle. User können z.B. auch einen kleinen Text über sich schreiben. Das würde dann alles dadrin stehen. Dachte das die Tabelle dann zu groß wird.

[Klawischnigg]

HI there,

Hm dachte halt das das die Abfrage sehr lahm machen wärde bei einer großen Tabelle.

Ja, auf einem 80386 ;)

User können z.B. auch einen kleinen Text über sich schreiben. Das würde dann alles dadrin stehen. Dachte das die Tabelle dann zu groß wird.

Im Prinzip ist es schon richtig, solche Umstände abzuwäge und zu berücksichtigen, aber wie gesagt, das allerwichtigste Prinzip ist immer noch:

keep it simple!!!

[Encoder]

keep it simple!!!

Guter Ansatz :-)
Dazu sollte man allerdings auch den Aufwand bei Änderungen bedenken. Wenn ich da an kommerzielle Projekte denke (also solche die wirklich stark genutzt werden, nicht unbedingt was privates mit 10 Usern, von denen ab dem dritten Monat keiner mehr reinschaut) dann würde ich Erweiterungen unbedingt mit einplanen.
Sonst stellt man x Stunden lang ein Projekt um, es funktioniert ewig nicht weil man doch noch ne Stelle im Code vergessen hat usw.

[Auge]

Hallo

... aber wie gesagt, das allerwichtigste Prinzip ist immer noch:

keep it simple!!!

Gut, dann ist dein Ansatz ja raus.

Tschö, Auge

[Tom]

Hello,

Ok, Du nennst es Spalten, ich nenne es Felder, je nachdem, ob man es von der Reräsentation in der Tabelle oder von einem Datensatz her betrachtet, aber nichtsdestotrotz spricht ja nichts gegen 35 Spalten, oder?

Die Lebensdauer dieses Sets könnte dagegen stehen.

Wenn aber sichergestellt ist, dass nur noch einige wenige Eigenschaften hinzukommen könnten über die Lebensdauer der gesamten Datenbank, dann könnte auch der Spaltentyp SET der richtige sein.

Von 35 bis 63 (?) Eigenschaften ist ja noch etwas Luft (aktuelle Wertebereiche finde ich gerade nicht)

http://dev.mysql.com/doc/refman/5.1/en/set.html

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[Klawischnigg]

Hi there,

Schön und gut nun habe ich aber das Problem der Datenredundanz.

Das wäre vor 20 Jahren noch ein Thema gewesen; bei modernen Rechnern ist das bei fast jeder Datenmenge einfach egal. Auch wenn Dein Einwand datentechnisch richtig ist, ökonomisch sinnvoll ist er nicht mehr, zumal Du Deinen Mehraufwand bei der Erstellung und der Wartung berücksichtigen muss...

[Tom]

Hello,

Schön und gut nun habe ich aber das Problem der Datenredundanz.

Das wäre vor 20 Jahren noch ein Thema gewesen; bei modernen Rechnern ist das bei fast jeder Datenmenge einfach egal. Auch wenn Dein Einwand datentechnisch richtig ist, ökonomisch sinnvoll ist er nicht mehr, zumal Du Deinen Mehraufwand bei der Erstellung und der Wartung berücksichtigen muss...

Wenn aber die Liste der Eigenschaften dynamisch ist, sich also ändern kann, dann ist es richtig, hier eine Abbildung aus der Horizontalen in die Vertikale durchzuführen.

Es muss dann bei einer Änderung des Wertevorrats der Eigenschaften keine Änderung am Datendesign und den Views vorgenommen werden, sondern nur ein neuer Datensatz hinzugefügt werden.

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[Klawischnigg]

HI there,

Wenn aber die Liste der Eigenschaften dynamisch ist, sich also ändern kann, dann ist es richtig, hier eine Abbildung aus der Horizontalen in die Vertikale durchzuführen.

Ja, hat er aber nicht gesagt;) Generell würd ich halt, wenn ich die Liste der Eigenschaften noch nicht kenne oder diese sich ändern kann einfach eine Tabelle mit den "Stammdaten" der User anlegen und eine mit Eigenschaften, die ich über einen unique-Key verknüpfe. Bei der Datenmenge, die bei dem vom OP angedeuteten Projekt idR anfällt eine durchaus praktikable Lösung.

Generell ist Dein Vorschlag aber technisch sicher der "richtigere"...

[Encoder]

Ich würd überall direkt den Wert reinschreiben, also nicht einmal die ID und einmal Deutschland. Das macht die Abfragen einfacher und vor allem sind IDs numerisch und "Deutschland" ist es nicht.

Und ich würd die Namen etwas kürzen. Mit user_information_information_option kannst du höchstens was anfangen während du dir das ausdenkst, aber nach einer Woche Pause bestimmt nicht mehr.

[Frido]

Ich würd überall direkt den Wert reinschreiben, also nicht einmal die ID und einmal Deutschland. Das macht die Abfragen einfacher und vor allem sind IDs numerisch und "Deutschland" ist es nicht.

Und wie soll das ganze dann aussehen?

[Encoder]

Und wie soll das ganze dann aussehen?

Dass du in die Spalte nicht einmal nen Einser (musst du auflösen) und einmal Deutschland (nicht auflösen) reinschreibst, sondern überall gleich den anzuzeigenden Wert.

[Frido]

Also es stehen hier kompetente Aussagen gegen kompetente Aussagen.

Ich weiß jetzt nicht mehr was ich machen soll
Ich habe es vorerst geändert in 2 Tabellen:

User
userid username useremail

Users_information
userid option1 option2 option3

Also der Vorschlag von Klaw...

Wenn ich ne Spalte hinzufügen will geht das schnell und löschen ja sowieso.

Gruß, Frido

[Auge]

Hallo

Also es stehen hier kompetente Aussagen gegen kompetente Aussagen.

Es gibt ja auch mehrere Wege nach Rom.

Ich weiß jetzt nicht mehr was ich machen soll
Ich habe es vorerst geändert in 2 Tabellen:

User
userid username useremail

Users_information
userid option1 option2 option3

Also der Vorschlag von Klaw...

Das ist aber alles 1 zu 1 (für jeden User jede Option einmal), also geht das auch in einer Tabelle.

Wenn ich ne Spalte hinzufügen will geht das schnell und löschen ja sowieso.

Wenn du da Optionen hinzufügen oder löschen willst, musst du jedesmal die Struktur der Tabelle ändern. Zudem musst du jedesmal die Queries (schreiben, lesen) für die DB ändern. Wie gesagt, wenn *das* und die Übergabe des Projekts an jemand anderen, der sich mit deinem System herumschlagen muss, unwahrscheinlich bis ausgeschlossen ist, kann man das machen. Wenn das *nicht* gegeben ist, sollte man _das_ System ganz schnell vergessen.

Tschö, Auge

[Frido]

Okay da gebe ich dir Recht.

Was hälst du von meinem Ausgangskonzept?

Gruß, Frido

[Auge]

Hallo

Okay da gebe ich dir Recht.

Was hälst du von meinem Ausgangskonzept?

Ich finde es zu kompliziert, wie gesagt, das kann mit ausreichender Flexibilität mit drei, maximal vier Tabellen[1] (inklusive der Benutzerdatentabelle) erledigt werden, also mit ein oder zwei Tabellen weniger als bei dir (du hast im Ausgangsposting _nicht_ die Benutzerdatentabelle in der Zählung drin).

[1]

• Benutzerdaten eines jeden Users
• Eigenschaftengruppen (die eventuelle, vierte Tabelle)
• Eigenschaften
• Verknüpfung der User mit den Eigenschaften

Tschö, Auge

[Frido]

Hi.

Mir ist gerade eiin anderes problem in den Kopf geschossen.
Während ich bei Klaw... Modell die Möglichkeit habe den unterschiedlichen Angaben unterschiedliche Typen zuweisen zu können, muss ich bei der bisherigen Methode ja einen Typen auswählen.

Ich denke also ich werde dann für die Inhalte VARCHAR(255) angeben - denn - man hat z.B. die Möglichkeit Interessen anzugeben.
Das können ja dann gut und gerne mal mehr sein.
Was aber dann reine Speicherplatzverschwendung ist wenn ich z.B. nur ein Geburtsdatum angebe, welches ja maximal 10 Stellen benötigt. dd.mm.yyyy

Aber es scheint mir auch am sinnvollsten so.

[ChrisB]

Hi,

Ich denke also ich werde dann für die Inhalte VARCHAR(255) angeben - denn - man hat z.B. die Möglichkeit Interessen anzugeben.
Das können ja dann gut und gerne mal mehr sein.

Die gehören aber eigentlich nicht in *ein* Feld - Spalteninahlte sollten atomar sein.
Wenn du das ganze natürlich ganz frei halten willst, also dass der Nutzer da beliebigen Freitext eingeben kann - dann geht's kaum anders.
Mit einer definierten Auswahl sähe das schon anders aus - Interessen wie Sport, Musik, ... könnten ja vorgegeben werden. Und bei Bedarf auch noch feiner unterteilt.

Man könnte das ganze natürlich auch wie ein Tagging-System aufbauen. Interessen werden in einer eigenen Tabelle abgelegt. Der Nutzer macht selber eine Eingabe, und dann schaut man erst mal, ob jemand anderes die schon gemacht - wenn ja, übernimmt man deren ID und verknüpft sie in einer weiteren Tabelle mit der User-ID; wenn nicht, dann wird zuerst ein neuer Eintrag angelegt. Das muss man natürlich ein bisschen "normalisieren" - bspw. Gross-/Kleinschreibung vereinheitlichen, etc.

Was aber dann reine Speicherplatzverschwendung ist wenn ich z.B. nur ein Geburtsdatum angebe, welches ja maximal 10 Stellen benötigt. dd.mm.yyyy

Was, das Geburtsdatum soll auch noch mit in diese ominöse "Interessen"-Feld ...?

Das speicherst du selbstverständlich in einem Feld mit einem passenden Typ (Datums-Typen von MySQL anschauen!) - und nicht in einem *Text*feld.

MfG ChrisB

[Frido]

Hi.

Die gehören aber eigentlich nicht in *ein* Feld - Spalteninahlte sollten atomar sein.

Sag mir bitte was du mit atomar meinst.

Wenn du das ganze natürlich ganz frei halten willst, also dass der Nutzer da beliebigen Freitext eingeben kann - dann geht's kaum anders.

[1]Ja richtig, er soll sagen können das er nur "ab und zu gerne mal" dies und das tut. Also es persönlich beschreiben können.

Man könnte das ganze natürlich auch wie ein Tagging-System aufbauen. Interessen werden in einer eigenen Tabelle abgelegt. Der Nutzer macht selber eine Eingabe, und dann schaut man erst mal, ob jemand anderes die schon gemacht - wenn ja, übernimmt man deren ID und verknüpft sie in einer weiteren Tabelle mit der User-ID; wenn nicht, dann wird zuerst ein neuer Eintrag angelegt. Das muss man natürlich ein bisschen "normalisieren" - bspw. Gross-/Kleinschreibung vereinheitlichen, etc.

Also per Ajax dann die vorhandenen Interessen vorschlagen. Aber das mache ich aus dem [1] genannten Grund nicht.

»» Was aber dann reine Speicherplatzverschwendung ist wenn ich z.B. nur ein Geburtsdatum angebe, welches ja maximal 10 Stellen benötigt. dd.mm.yyyy

Was, das Geburtsdatum soll auch noch mit in diese ominöse "Interessen"-Feld ...?

Ich verdeutliche das ganze nochmal.
Es geht nicht um die reinen Interessen es geht um das _Profil_ des Nutzers, in welches auch das Geburtsdatum reingehört denn es wird maximal im Profil angezeigt!

Das speicherst du selbstverständlich in einem Feld mit einem passenden Typ (Datums-Typen von MySQL anschauen!) - und nicht in einem *Text*feld.

Das ist mir schon klar (Date). Ich würde auch die PLZ der Herkunft nicht in einem Textfeld speichern sondern einem INT-Feld und auch ob m oder w würde ich in einem CHAR-Feld speicher, am liebsten würde ich auch den Usern die Möglichkeit geben einen Text über sich zu schreiben der länger als 255 Zeichen ist (TEXT).
Aber das ist nach Auges Modell nunmal nicht möglich, ich muss also einen guten TYP für alles finden. Text finde ich zu groß, deswegen wird es wohl VARCHAR bleiben - siehst du das anders?

Gruß,

Frido

[ChrisB]

Hi,

Wenn du das ganze natürlich ganz frei halten willst, also dass der Nutzer da beliebigen Freitext eingeben kann - dann geht's kaum anders.

Ja richtig, er soll sagen können das er nur "ab und zu gerne mal" dies und das tut. Also es persönlich beschreiben können.

Also wirklich Freitext, und nicht deklarativ "meine Interessen sind: ..."

Es geht nicht um die reinen Interessen es geht um das _Profil_ des Nutzers, in welches auch das Geburtsdatum reingehört denn es wird maximal im Profil angezeigt!

Gut, aber das Geburtsdatum und der Freitext sind noch mal zwei verschiedene Daten.

Das ist mir schon klar (Date). Ich würde auch die PLZ der Herkunft nicht in einem Textfeld speichern sondern einem INT-Feld

Das wäre falsch. Postleitzahlen sind keine Zahlenwerte.

und auch ob m oder w würde ich in einem CHAR-Feld speicher,

Dafür wäe vielleicht eher ein ENUM angebracht.

am liebsten würde ich auch den Usern die Möglichkeit geben einen Text über sich zu schreiben der länger als 255 Zeichen ist (TEXT).

Ja dann mach das doch einfach.

Aber das ist nach Auges Modell nunmal nicht möglich, ich muss also einen guten TYP für alles finden.

Nein, nein, nein.

Text finde ich zu groß, deswegen wird es wohl VARCHAR bleiben - siehst du das anders?

Wenn du mehr als 255 Zeichen ermöglichen willst, dann nimm kein VARCHAR.

Und was bedeutet eigentlich "zu gross"? Meinst du hinsichtlich der maximalen Textlänge, die der Nutzer eingeben kann? Dann beschränke diese in deiner Applikation.
Oder meinst du hinsichtlich Speicherverbrauch? Dann informiere dich, um deinen offensichtlichen Irrglauben bzgl. diesem zu korrigieren.

MfG ChrisB

[Frido]

Hi.

Also wirklich Freitext, und nicht deklarativ "meine Interessen sind: ..."

Ja richtig.

Gut, aber das Geburtsdatum und der Freitext sind noch mal zwei verschiedene Daten.

Das stimmt.

Das wäre falsch. Postleitzahlen sind keine Zahlenwerte.

Sondern? es sind doch immer x zahlen: 41066 Rheydt, 41065 Möncengladbach usw

»» Aber das ist nach Auges Modell nunmal nicht möglich, ich muss also einen guten TYP für alles finden.

Nein, nein, nein.

Wieso nicht?
Schau. Wenn ich eine Tabelle mache mit den Eigenschaften
int id, varchar eigenschaft
0, religion
1, herkunft
2, geburtstag

und dann ne 2. tabelle mache wo dann die userid, die eigenschaftsid und der wert drinsteht - also 3 spalten. Wie kann ich dann dafür unterschiedliche Typen nehmen?

int eigenschaftsid, int userid, varchar eigenschaft
0, 1, evangelisch
1, 1, deutschland
2, 1, 09.09.1084

Also ich verstehe nicht wie das gehen soll wenn ich mit nur 3 Spalten auskommen will.

Und was bedeutet eigentlich "zu gross"? Meinst du hinsichtlich der maximalen Textlänge, die der Nutzer eingeben kann? Dann beschränke diese in deiner Applikation.
Oder meinst du hinsichtlich Speicherverbrauch? Dann informiere dich, um deinen offensichtlichen Irrglauben bzgl. diesem zu korrigieren.

Ich dachte das die Typen unterschiedlich viel Speicher reservieren und das dadurch dann das ganze langsamer wird.
Gruß, Frido

[Auge]

Hallo

»» Das wäre falsch. Postleitzahlen sind keine Zahlenwerte.

Sondern? es sind doch immer x zahlen: 41066 Rheydt, 41065 Möncengladbach usw

PLZ sind Text der aus Ziffern besteht, es gibt schließlich auch PLZ, die mit einer 0 beginnen (Sachsen, Thüringen). Das kann in einem Zahlenfeld nicht abgebildet werden (05303 würde als 5303 gespeichert werden).

»» »» Aber das ist nach Auges Modell nunmal nicht möglich, ich muss also einen guten TYP für alles finden.
»»
»» Nein, nein, nein.

Wieso nicht?
Schau. Wenn ich eine Tabelle mache mit den Eigenschaften
int id, varchar eigenschaft
0, religion
1, herkunft
2, geburtstag

und dann ne 2. tabelle mache wo dann die userid, die eigenschaftsid und der wert drinsteht - also 3 spalten. Wie kann ich dann dafür unterschiedliche Typen nehmen?

int eigenschaftsid, int userid, varchar eigenschaft
0, 1, evangelisch
1, 1, deutschland
2, 1, 09.09.1084

Also ich verstehe nicht wie das gehen soll wenn ich mit nur 3 Spalten auskommen will.

Nimm in der zweiten Tabelle ein weiteres Feld hinzu, welches die ID der Eigenschaft aus der oberen Tabelle abbildet.

Deine erste Tabelle (Eigenschaften):

int id, varchar eigenschaft
1, religion
2, herkunft
3, geburtstag

Deine zweite Tabelle (Eigenschaftswerte):

int id, int userid, varchar eigenschaftswert, int eigenschaftsid (aus der oberen Tabelle)
1, 1, evangelisch, 1 (nochmal: es gibt keine ID "0", die beginnen bei "1")
2, 1, deutschland, 2
3, 1, 09.09.1084, 3

Tschö, Auge

[Frido]

Hi.

PLZ sind Text der aus Ziffern besteht, es gibt schließlich auch PLZ, die mit einer 0 beginnen (Sachsen, Thüringen). Das kann in einem Zahlenfeld nicht abgebildet werden (05303 würde als 5303 gespeichert werden).

Stimmt, danke für den Tipp.

Nimm in der zweiten Tabelle ein weiteres Feld hinzu, welches die ID der Eigenschaft aus der oberen Tabelle abbildet.

Hä? Dadurch wird das Problem des Spaltentyps doch nicht behoben.

Deine erste Tabelle (Eigenschaften):

int id, varchar eigenschaft
1, religion
2, herkunft
3, geburtstag

Ist klar.

Deine zweite Tabelle (Eigenschaftswerte):

int id, int userid, varchar eigenschaftswert, int eigenschaftsid (aus der oberen Tabelle)
1, 1, evangelisch, 1 (nochmal: es gibt keine ID "0", die beginnen bei "1")
2, 1, deutschland, 2
3, 1, 09.09.1084, 3

Jetzt wird doch immernoch das Geburtsdatum innem VARCHAR-Feld gespeichert.
Und wozu jeder Relation noch ne ID zuweisen?

Bye, Frido

[Auge]

Hallo

»» Deine zweite Tabelle (Eigenschaftswerte):
»»
»» int id, int userid, varchar eigenschaftswert, int eigenschaftsid (aus der oberen Tabelle)
»» 1, 1, evangelisch, 1 (nochmal: es gibt keine ID "0", die beginnen bei "1")
»» 2, 1, deutschland, 2
»» 3, 1, 09.09.1084, 3

Jetzt wird doch immernoch das Geburtsdatum innem VARCHAR-Feld gespeichert.

Das Geburtsdatum gehört ja auch garnicht in diese Tabelle. Das gehört direkt zu den Benutzerdaten. "Hier" gehören "Kannangaben" hin, die verschiedene Werte haben können (wie z.B. Religion oder bevorzugte Musikgenres).

Und wozu jeder Relation noch ne ID zuweisen?

Das musst du nicht auch machen, die Verknüpfungstabelle (Benutzer zu Wert) braucht keine eigene ID-Spalte. *Ich* möchte zu *jedem* Eintrag in der DB auch eine ID haben, weshalb ich eine entsprechende Spalte in jede Tabelle einfüge.

Tschö, Auge

[Tom]

Hello,

PLZ sind Text der aus Ziffern besteht, es gibt schließlich auch PLZ, die mit einer 0 beginnen (Sachsen, Thüringen). Das kann in einem Zahlenfeld nicht abgebildet werden (05303 würde als 5303 gespeichert werden).

Hinzu kommt noch stringorientierte Bedeutung der Ziffernposition.

1.   Stelle = Postleitzone 0 - 9
2.   Stelle = Postleitregion innerhalb der Zone
3-5. Stelle = Bezirks-/Postfachstandort-Kennung innerhalb der Region, variabel aufgeteilt

Das bedeutet, dass man unter z.B. 37 die Postleitregion 37xxx versteht und nicht den Bezirk 037.

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[ChrisB]

Hi,

Oder meinst du hinsichtlich Speicherverbrauch? Dann informiere dich, um deinen offensichtlichen Irrglauben bzgl. diesem zu korrigieren.

Ich dachte das die Typen unterschiedlich viel Speicher reservieren und das dadurch dann das ganze langsamer wird.

Wenn ich sage, informiere dich bitte, dann meine ich auch das ...

http://dev.mysql.com/doc/refman/5.1/en/storage-requirements.html

MfG ChrisB