[Erledigt] Frei definierbare Profilfelder

bembelimen · 09.02.2010, 18:03

Hallo

Ich bastel gerade an einem Userprofil mittels PHP/MySQL. Soweit kein Problem, mir tut sich nur die Frage auf, wie ich frei definierte Felder in der Datenbank speichern soll. Das heißt, ich will z.B. ein Feld "Hobbies", dass ich in einer Administration erstelle.

Auf der einen Seite habe ich nun eine Datenbanktabelle:

Code:

id|name|label|type|length|order|published

In diesem würde dann beim oben genannten Beispiel folgendes stehen:

Code:

1|hobbies|Hobbies|text|50|1|1

Auf der anderen Seite habe ich die normale Usertabelle (mit ein paar fest definierten Felder):

Code:

id|username|password|name|...

Funktioniert alles auch und das Feld wird angezeigt. Doch nun stellt sich die Frage, wie ich das speichere. Ich habe mich vorher ein bisschen schlau gemacht und bin auf folgende zwei Möglichkeiten gestoßen:

1. Ich nehme eine zusätzliche Tabelle, die ich mittels "ALTER" bei jedem neuen Feld erweitere. Diese Tabelle "joine" ich dann zu der Usertabelle
2. Ich mache ein zusätzliches Textfeld an die Usertabelle (sagen wir "additional_info") in die ich für jeden User die Werte folgendermaßen speichere:

Code:

feld1=foo
feld2=bar
feld3=blub
...

und dann später alles per "explode" trenne.

So nun stellen sich für mich folgende Fragen:

- Habe ich eine Speichermethode übersehen, die vielleicht besser ist als die zwei von mir?
- Hat schon mal jemand damit Erfahrung gemacht und kann eine der zwei empfehlen?

Falls die erste Methode die bessere ist:

- Ist es "gesund" mittels "ALTER" immer die Datenbanktabelle zu verändern? (vom Hörensagen heißt es, das dies nicht sehr gut ist, gibt es da Erfahrungen?)

Falls die zweite besser ist:

- Wie mache ich die letzte Methode performant durchsuchbar? So wie ich das verstehe, müsste ich eine LIKE Suche nutzen und dann alles per PHP nachsortieren (im Gegensatz zur ersten, wo ich sehr einfach einzelne Felder durchsuchen kann)

Vielen Dank für mögliche Antworten. Ich würde mich auch über Links freuen, die mir weiterhelfen eine Entscheidung zu treffen.

Gruß
bembelimen

nikosch · 09.02.2010, 18:08

Weder 1 noch 2.

Code:

Usersettings
UserID | SettingID | Value varchar(250)
PK(UserID , SettingID)

SettingID ref. id aus Deinem ersten Blockposting
Value kann auch andere Feldtypen haben, massgeblich ist der „größte“ benötigte.

Code:

Users 
ID   | Name   | ...
0815 |  Horst |
0845 |  Maria |

SettingFields
id | name       | label                   | type | ...
1  | hobbies    | Hobbies                 | text | 50  | 1 | 1
2  | frameworks | Welche FW verwendest Du | text | 200 | 1 | 1

Usersettings
UserID | SettingID | Value varchar(250)
0845   | 1         | Fahrradfahren
0815   | 2         | Zend Framework
0815   | 1         | Lesen, Kino

ragtek · 09.02.2010, 18:21

Darf man fragen, wieso du das nicht in die Users Tabelle speichern würdest?

Das ist auch so ein Szenario, wo ich noch keinen klaren Vorteil zw. "eigener Tabelle" und "zu den Benutzern speichern" sehe.

nikosch · 09.02.2010, 18:24

Weil es um variable Angaben geht. Ein ALTER der Tabelle bei jedem Konfigurationsseting ist in meinen Augen eine echt schlechte Lösung.

ragtek · 09.02.2010, 18:30

Ja, das habe ich mir früher auch gedacht, aber wie oft ändert man das den in der Praxis?
Einmal bei der installation und eventuell alle paar Monate mal, wo mich der ALTER Befehl nicht wirklich stört.

Früher, wo auch leere Datenbankspalten speicher benötigt haben (habe ich zumindest so gelernt, kA ob es der Realität entspricht) hat/hätte es natürlich Sinn gemacht, dafür eine eigene Tabelle zu erstellen, aber da es soweit ich weiß mittlerweile nicht mehr so ist, sehe ich keinen wirklichen Grund.

nikosch · 09.02.2010, 19:03

Dass keine leeren Felder entstehen ist eigentlich nur Abfall des Prinzips, was mich stört ist das ALTER im anderen Fall.
Im Idealfall muss man ein Datenbankschema überhaupt nicht mehr antasten. Auch wenn es nur selten passiert ist ALTER in diesem Fall aber ein Vorgang im Ablauf der Anwendung (Administration der Applikation) und damit unsauber. ALTER sollte IMHO nie im Code vorkommen, allenfalls in einem Installer.

Oder stell Dir mal vor, Du willst Deiner Anwendung noch beibringen, bestimmte Daten zu erheben, aber nicht anzuzeigen. Führst Du dann noch eine zusätzliche Spalte pro Datum ein? Und wie verknüpfst Du die Information Sichtbarkeit und Zugehörigkeit zu einem Datum? Über den Namen? Und stell Dir jetzt vor, Du willst die Sichtbarkeit abhängig vom Status des Websitebesuchers definieren können. Wieder ein neues Feld? Wieder eine Namenskonvention?

Code:

Usersettings
UserID | SettingID | Value varchar(250) | [[public] | publicForGroupID]

ragtek · 09.02.2010, 19:26

Zitat:

Zitat von nikosch

Oder stell Dir mal vor, Du willst Deiner Anwendung noch beibringen, bestimmte Daten zu erheben, aber nicht anzuzeigen. Führst Du dann noch eine zusätzliche Spalte pro Datum ein? Und wie verknüpfst Du die Information Sichtbarkeit und Zugehörigkeit zu einem Datum? Über den Namen? Und stell Dir jetzt vor, Du willst die Sichtbarkeit abhängig vom Status des Websitebesuchers definieren können. Wieder ein neues Feld? Wieder eine Namenskonvention?

Bei komplexeren Feldern würde ich die Feldeigenschaften in einer eigenen Tabelle speichern, aber die Werte trotzdem beim Benutzer.
Aber, nichts desto trotz, kann ich den Weg über 2 Tabellen und eine "saubere Umsetzung" ohne ALTER auch nachvollziehen.

Ich hoffe das ich dich richtig verstanden habe.

nikosch · 09.02.2010, 19:57

bembelimen · 09.02.2010, 21:25

Hallo

Vielen Dank für die Antworten.

Ganz am Anfang habe ich (bedingt durch diesen Beitrag (mehrere Variablen aus einer Spalte auftrennen)) auch erst überlegt eine solche Datenbankstruktur zu erstellen. Meine Bedenken dahingehend waren aber, dass es evtl. ein bisschen eklig wird, wenn ich mal "per Hand" da drin herumschrauben will/muss. Aber ich denke nun, dass ich diesen "Nachteil" verkraften kann und dieses System nutzen werden. Vielen Dank für den Schubs dahin

Der Grund warum ich eine eigene Tabelle machen will ist ein ganz einfacher: Ich hänge mich mit den flexiblen Felder in ein bestehendes System und will so wenig wie möglich das Grundsystem beeinflussen. Und falls mir etwas um die Ohren fliegt, dann soll es nur das angehängt sein und nicht das komplette.

Edit: Was mir gerade noch auffällt: wenn ich das richtig sehe, dann muss ich für jeden User einen eigenen Select machen, wenn ich alle Felder auslesen will, oder? (in etwa: SELECT b.* FROM SettingFields a LEFT JOIN Usersettings b ON b.SettingID=a.id WHERE a.UserID=1)

Gruß
bembelimen

nikosch · 09.02.2010, 23:38

Zitat:

Edit: Was mir gerade noch auffällt: wenn ich das richtig sehe, dann muss ich für jeden User einen eigenen Select machen, wenn ich alle Felder auslesen will, oder?

Nö. Entweder nen normalen JOIN, dann hast Du doppelte Usernamen etc + jeweils einen Setting-Eintrag

oder

Du benutzt etwas wie GROUP_CONCAT.

Themen-Optionen
Druckbare Version zeigen Jemanden per E-Mail auf dieses Thema hinweisen
Thema bewerten
Thema bewerten:

Ähnliche Themen
Thema	Autor	Forum	Antworten	Letzter Beitrag
Berlin: Webentwickler sucht Job fest oder frei	allphp	Beitragsarchiv	1	15.06.2009 16:58
dienste abfrage - shoutcast frei? script	Snape	PHP Tipps 2008	10	22.09.2008 11:54
Abfrage, ob frei Tabellenzeile vorhanden ist	leuktra	Datenbanken	4	26.07.2006 17:03
[Erledigt] Textarea: Noch x Zeichen frei...		HTML, Usability und Barrierefreiheit	5	10.05.2006 09:48
Frei nach Schnauze vertauschen :D	Skazi	PHP Tipps 2007	3	11.12.2005 15:24
merX Webdesign - Ressourcen frei!		Beitragsarchiv	14	21.08.2005 00:24
Frei editierbare Rechte	Mano	PHP Tipps 2005-2	9	20.08.2005 17:34
[Suche] Script -> Banerklick -> Download Frei		Beitragsarchiv	5	27.04.2005 14:46
[Erledigt] Bilder frei positionieren und von Text umfließen lassen.		HTML, Usability und Barrierefreiheit	10	24.04.2005 00:05
Professioneller PHP-Entwickler hat Kapazitäten frei	phpprofi	Beitragsarchiv	1	08.02.2005 10:03
Freiberuflicher PHP-Prof hat Kapazitäten frei	phpprofi	Beitragsarchiv	1	30.12.2004 10:26
gebe code frei zu lernzwecken!		PHP Tipps 2004	8	22.07.2004 11:01
gifs bald frei verfügbar!!! freude???		Off-Topic Diskussionen	5	27.06.2004 12:59

09.02.2010, 18:03
bembelimen Neuer Benutzer Registriert seit: 20.12.2009 Beiträge: 16 PHP-Kenntnisse: Anfänger	[Erledigt] Frei definierbare Profilfelder Hallo Ich bastel gerade an einem Userprofil mittels PHP/MySQL. Soweit kein Problem, mir tut sich nur die Frage auf, wie ich frei definierte Felder in der Datenbank speichern soll. Das heißt, ich will z.B. ein Feld "Hobbies", dass ich in einer Administration erstelle. Auf der einen Seite habe ich nun eine Datenbanktabelle: Code: id\|name\|label\|type\|length\|order\|published In diesem würde dann beim oben genannten Beispiel folgendes stehen: Code: 1\|hobbies\|Hobbies\|text\|50\|1\|1 Auf der anderen Seite habe ich die normale Usertabelle (mit ein paar fest definierten Felder): Code: id\|username\|password\|name\|... Funktioniert alles auch und das Feld wird angezeigt. Doch nun stellt sich die Frage, wie ich das speichere. Ich habe mich vorher ein bisschen schlau gemacht und bin auf folgende zwei Möglichkeiten gestoßen: 1. Ich nehme eine zusätzliche Tabelle, die ich mittels "ALTER" bei jedem neuen Feld erweitere. Diese Tabelle "joine" ich dann zu der Usertabelle 2. Ich mache ein zusätzliches Textfeld an die Usertabelle (sagen wir "additional_info") in die ich für jeden User die Werte folgendermaßen speichere: Code: feld1=foo feld2=bar feld3=blub ... und dann später alles per "explode" trenne. So nun stellen sich für mich folgende Fragen: - Habe ich eine Speichermethode übersehen, die vielleicht besser ist als die zwei von mir? - Hat schon mal jemand damit Erfahrung gemacht und kann eine der zwei empfehlen? Falls die erste Methode die bessere ist: - Ist es "gesund" mittels "ALTER" immer die Datenbanktabelle zu verändern? (vom Hörensagen heißt es, das dies nicht sehr gut ist, gibt es da Erfahrungen?) Falls die zweite besser ist: - Wie mache ich die letzte Methode performant durchsuchbar? So wie ich das verstehe, müsste ich eine LIKE Suche nutzen und dann alles per PHP nachsortieren (im Gegensatz zur ersten, wo ich sehr einfach einzelne Felder durchsuchen kann) Vielen Dank für mögliche Antworten. Ich würde mich auch über Links freuen, die mir weiterhelfen eine Entscheidung zu treffen. Gruß bembelimen


Mister Ad PHP Code Flüsterer Registriert seit: 21.08.2005 Beiträge: 4682 PHP-Kenntnisse: Fortgeschritten

09.02.2010, 18:08
nikosch moderatives Dielektrikum Registriert seit: 21.05.2008 Beiträge: 35.987 PHP-Kenntnisse: Fortgeschritten	Weder 1 noch 2. Code: Usersettings UserID \| SettingID \| Value varchar(250) PK(UserID , SettingID) SettingID ref. id aus Deinem ersten Blockposting Value kann auch andere Feldtypen haben, massgeblich ist der „größte“ benötigte. Code: Users ID \| Name \| ... 0815 \| Horst \| 0845 \| Maria \| SettingFields id \| name \| label \| type \| ... 1 \| hobbies \| Hobbies \| text \| 50 \| 1 \| 1 2 \| frameworks \| Welche FW verwendest Du \| text \| 200 \| 1 \| 1 Usersettings UserID \| SettingID \| Value varchar(250) 0845 \| 1 \| Fahrradfahren 0815 \| 2 \| Zend Framework 0815 \| 1 \| Lesen, Kino __________________ -- One pixel is still too big. Please make it smaller. ASAP. Initiative Mittelstand. Die wichtigste Gestaltungsregel im Screendesign ist Pi mal Daumen des Arbeitgebers. -- Geändert von nikosch (09.02.2010 um 18:12 Uhr).

09.02.2010, 18:21
ragtek Erfahrener Benutzer Registriert seit: 10.02.2009 Beiträge: 929	Darf man fragen, wieso du das nicht in die Users Tabelle speichern würdest? Das ist auch so ein Szenario, wo ich noch keinen klaren Vorteil zw. "eigener Tabelle" und "zu den Benutzern speichern" sehe.

09.02.2010, 18:24
nikosch moderatives Dielektrikum Registriert seit: 21.05.2008 Beiträge: 35.987 PHP-Kenntnisse: Fortgeschritten	Weil es um variable Angaben geht. Ein ALTER der Tabelle bei jedem Konfigurationsseting ist in meinen Augen eine echt schlechte Lösung. __________________ -- One pixel is still too big. Please make it smaller. ASAP. Initiative Mittelstand. Die wichtigste Gestaltungsregel im Screendesign ist Pi mal Daumen des Arbeitgebers. --

09.02.2010, 18:30
ragtek Erfahrener Benutzer Registriert seit: 10.02.2009 Beiträge: 929	Ja, das habe ich mir früher auch gedacht, aber wie oft ändert man das den in der Praxis? Einmal bei der installation und eventuell alle paar Monate mal, wo mich der ALTER Befehl nicht wirklich stört. Früher, wo auch leere Datenbankspalten speicher benötigt haben (habe ich zumindest so gelernt, kA ob es der Realität entspricht) hat/hätte es natürlich Sinn gemacht, dafür eine eigene Tabelle zu erstellen, aber da es soweit ich weiß mittlerweile nicht mehr so ist, sehe ich keinen wirklichen Grund.

09.02.2010, 19:03
nikosch moderatives Dielektrikum Registriert seit: 21.05.2008 Beiträge: 35.987 PHP-Kenntnisse: Fortgeschritten	Dass keine leeren Felder entstehen ist eigentlich nur Abfall des Prinzips, was mich stört ist das ALTER im anderen Fall. Im Idealfall muss man ein Datenbankschema überhaupt nicht mehr antasten. Auch wenn es nur selten passiert ist ALTER in diesem Fall aber ein Vorgang im Ablauf der Anwendung (Administration der Applikation) und damit unsauber. ALTER sollte IMHO nie im Code vorkommen, allenfalls in einem Installer. Oder stell Dir mal vor, Du willst Deiner Anwendung noch beibringen, bestimmte Daten zu erheben, aber nicht anzuzeigen. Führst Du dann noch eine zusätzliche Spalte pro Datum ein? Und wie verknüpfst Du die Information Sichtbarkeit und Zugehörigkeit zu einem Datum? Über den Namen? Und stell Dir jetzt vor, Du willst die Sichtbarkeit abhängig vom Status des Websitebesuchers definieren können. Wieder ein neues Feld? Wieder eine Namenskonvention? Code: Usersettings UserID \| SettingID \| Value varchar(250) \| [[public] \| publicForGroupID] __________________ -- One pixel is still too big. Please make it smaller. ASAP. Initiative Mittelstand. Die wichtigste Gestaltungsregel im Screendesign ist Pi mal Daumen des Arbeitgebers. -- Geändert von nikosch (09.02.2010 um 19:12 Uhr).

09.02.2010, 19:57
nikosch moderatives Dielektrikum Registriert seit: 21.05.2008 Beiträge: 35.987 PHP-Kenntnisse: Fortgeschritten	Ja. __________________ -- One pixel is still too big. Please make it smaller. ASAP. Initiative Mittelstand. Die wichtigste Gestaltungsregel im Screendesign ist Pi mal Daumen des Arbeitgebers. --

09.02.2010, 21:25
bembelimen Neuer Benutzer Registriert seit: 20.12.2009 Beiträge: 16 PHP-Kenntnisse: Anfänger	Hallo Vielen Dank für die Antworten. Ganz am Anfang habe ich (bedingt durch diesen Beitrag (mehrere Variablen aus einer Spalte auftrennen)) auch erst überlegt eine solche Datenbankstruktur zu erstellen. Meine Bedenken dahingehend waren aber, dass es evtl. ein bisschen eklig wird, wenn ich mal "per Hand" da drin herumschrauben will/muss. Aber ich denke nun, dass ich diesen "Nachteil" verkraften kann und dieses System nutzen werden. Vielen Dank für den Schubs dahin Der Grund warum ich eine eigene Tabelle machen will ist ein ganz einfacher: Ich hänge mich mit den flexiblen Felder in ein bestehendes System und will so wenig wie möglich das Grundsystem beeinflussen. Und falls mir etwas um die Ohren fliegt, dann soll es nur das angehängt sein und nicht das komplette. Edit: Was mir gerade noch auffällt: wenn ich das richtig sehe, dann muss ich für jeden User einen eigenen Select machen, wenn ich alle Felder auslesen will, oder? (in etwa: SELECT b.* FROM SettingFields a LEFT JOIN Usersettings b ON b.SettingID=a.id WHERE a.UserID=1) Gruß bembelimen Geändert von bembelimen (09.02.2010 um 21:47 Uhr).