Clanintern Clanintern Clanintern

Forum

Öffentliche Foren
FORUM: Spiele & Computer THEMA: Schemaänderungen
AUTOR BEITRAG
vaest´ark // patrick *ich bin hier nicht der depp*

RANG Master of Clanintern

#1 - 23.06 18:52

Hallo Forum,

ja, der nichts-sagende Threadtitel ist mehr oder weniger Absicht, weil ich selber nicht wusste wie ich das am Besten beschreibe.
Also, folgende Absicht:
Ich gebe meinen Benutzern folgendes, starres Eingabefeldschema an die Hand:
Name, Vorname, Geschlecht, Geburtstag
Die Daten werden genau so in der Datenbanktabelle hinterlegt.
Jetzt will ich aber, das der Admin selbst entscheiden kann, welche Daten er erfassen will, beispielsweise
Vorname, E-Mail, Alter, ICQ-Kontakt, Bildschirmdiagonale
Diese Daten müssen zwingend in der selben Datenbanktabelle hinterlegt werden.

Wie realisiert man sowas?
Für jede nicht vorhandene Spalte ein "alter table" durchführen und einfach dranhängen, die benutzten Spalten in einer separaten Tabelle aufführen? Ziemlich inperformant und bei genauerer Betrachtung auch nicht sooo sehr schön.

Einfach eine hinreichend breite Tabelle anlegen und "generische" Spaltennamen vergeben, dann eine zweite Tabelle zur Benamung der Spalten verwenden?

Vielleicht hab ich einfach ein Brett vor dem Kopf,...
Danke für jeden Hinweis

LG,
.pat

(edit)
Das lässt sich natürlich auch auf eine per-User-Einstellung übertragen, in dem man z.B. sagt, das die Benutzer sich selbst aussuchen dürfen, welche Spalten sie angezeigt haben möchten (ok, das wäre im Endeffekt eine Spur einfacher zu realisieren).
phoeniks

RANG Godlike

#2 - 23.06 21:24

Also ich würde zur zweiten Variante tendieren - Tabelle mit generischen Spaltennamen und dann eine weitere Tabelle mit den vom Admin festgelegten Bezeichnungen. Was Besseres als das fällt mir grad auch nicht ein.
*al!ve* - Vorbereitung aufs Urlaubssemester

RANG Master of Clanintern

#3 - 24.06 00:00

Warum ist es zwingend, dass die Daten in der selben Tabelle stehen?
Mir ist klar dass es enorm unperformant ist, aber ich würde eine Tabelle mit den Attributen "schlüssel" und "wert" anlegen und die da drin dann lagern.

Benutzer: (int) id (Primärschlüssel), (string) name
Evtl statistische Daten die der Admin nicht ändern darf und solche, die nur systemintern verwendet werden.

Attribut: (int) Benutzer (Fremdschlüssel auf Benutzer), (string) schluessel, (string) wert

Wahlweise auf Gruppen, Benutzer oder Programmebene definieren, welche Attribute es gibt und einen entsprechenden Select speichern, der einen Benutzer und alle seine Attribute liefert:
code:
SELECT ben.*
, attr_a.wert AS geschlecht
, attr_b.wert AS geburtstag
, attr_c.wert AS icq
FROM benutzer ben
LEFT JOIN attribut att_a ON ben.id = attr_a.benutzer
LEFT JOIN attribut att_b ON ben.id = attr_b.benutzer
LEFT JOIN attribut att_c ON ben.id = attr_c.benutzer


Sowas lässt sich wie man sieht leicht automatisiert zusammenbauen.

Da müsste dann natürlich ne entsprechende Klasse hinter, die Inserts und Updates kapselt und entsprechend modifiziert. Diesen Select als Art temporären View betrachten und darauf dann nicht nur lesen sondern auch modifizieren werden die meisten im Web üblichen DBMS wohl nicht können.
vaest´ark // patrick *ich bin hier nicht der depp*

RANG Master of Clanintern

#4 - 24.06 15:42

Das soll zwingend in der selben Tabelle liegen, weil ich nicht für jedes Schema eine eigene Tabelle erstellen kann (naja, eher weil ich das nicht will ).
Dann hätte ich ja für 5 verschiedene Schemen 5 verschiedene Tabellen mit nur einer kleinen Anzahl an Datensätzen drin. Und es werden sicher deutlich mehr. Also auch nicht so das Optimum.

Die Lösung von dir, alive, ist wohl in meinen Augen die schlechtest mögliche. Es ist leider nur in den seltensten Fällen mit weniger als 5 Attributen zu rechnen, eher sinds in der Gegend um die 15.
Dann noch der Aufwand mit den zu modifizierenden Abfragen... ne, danke.
Am liebsten wär es mir, wenn ich mit 2-5 Standard-SQL-Abfragen die Daten rein und wieder raus kriege.

Bis jetzt tendiere ich auch zur generischen Tabelle. Widerspricht zwar zu 100% der Normalisierung in jedweder Form, aber anders gehts wohl nicht wenn ich nicht für jedes Schema ne eigene Tabelle anlegen will.
horst

RANG Prophet of Clanintern

#5 - 24.06 15:51

Mal so gefragt... Muss man nach den Attributen suchen können und falls ja in welcher Form :-) ? Andernfalls kannst du doch auch eine Art CSV Spalten pro User anlegen (für Kopf und Inhalt).
k-to-the-laus(topher)

RANG Master of Luck

#6 - 24.06 15:58

Naja, meine Idee wäre, ein Feld vom Typ TEXT anzulegen und dort dann ein serialisiertes Array drin abzulegen mit den erweiterten Daten. Dann eine weitere Tabelle, wo dann alle zusätzlichen Eingabefelder drin aufgelistet werden...

So hast du das ganze in einer Abfrage und musst den Array dann halt nurnoch unserialisieren


Oder halt so wie alive sagt. Aber ich würd die Abfrage dann mit 2 Queries machen:
SELECT * FROM usertabelle WHERE id=1
SELECT * FROM erweiterteFelder WHERE id=1

wobei erweitertefelder= (int)userid, (varchar)key, (varchar)val wäre.
vaest´ark // patrick *ich bin hier nicht der depp*

RANG Master of Clanintern

#7 - 24.06 16:10

Oh, ja. Die Suche sollte natürlich schon irgendwie möglich sein, vorzugsweise natürlich direkt auf der Datenbank ohne Verrenkungen im Code.
Das serialisierte Array ist dann schon raus (wars eigentlich eh, die Lösung ist mir einfach ZU abgedreht).
Die Attributtabelle könnte man zur Not auch noch Durchsuchen, wäre aber auch ein relativ hoher Overhead...
Na, alles noch nicht so das wahre...