[heohni]

Hallo,

ich komme grad in meiner Überlegung nicht weiter und wollte mal die Meinung eines anderen hören.

Also es geht um folgendes:

Für ein mehrsprachiges Portal habe ich mir so eine Art Formular-Generator geschrieben, mit dessen Hilfe ich mir einzelne Formular Element erstellen kann.



Diese Werte speichere ich dann so ab:





featureID = autoincrement
categoryID = Kategorie
sort = position zum auf- und ab sortieren
type = kennzeichnung ob text feld, radio, checkbox, etc
require = pflichtfeld ja/nein
transrequire = Übersetzung notwendig ja/nein

Die Beschriftungen speichere ich in einer anderen Tabelle:







Lang_id steht für die jeweilige Sprache. Es können beliebig viele Sprachen im System existieren.



Soweit – so gut.

Wo ich jetzt echt festsitze ist, wie ich die Elemente (features) nun für weitere Kategorien speichere.
Ich könnte natürlich in der ersten Tabelle einfache alle Zeilen mit einer neuen categoryID wiederholen… aber das erscheint mir igendwie doof und unnötig, zumal ich dadurch gezwungen bin, auch die Werte in der zweiten Tabelle zigmale zu wiederholen.

Andererseits, nicht jede Kategorie hat dieselben Felder. Eine andere Kategorie könnte weniger/mehr/andere Elemente besitzen.

Und hier stecke ich fest… weiß nicht, wie ich es am besten und unkompliziertesten löse, so das mir meine Dynamic dabei nicht verloren geht.



Welchen Eindruck macht das ganze auf Euch?
Hattes Ihr mal ähnliche Probleme? Wie würdet Ihr nun weitermachen?



Bin sehr neugierig auf Eure Antworten!

[MrNiceGuy]

Also erstmal muss ich loswerden, dass du für das Feld `type` lieber den Typ ENUM nutzen solltest. Da gibst du dann die Werte entsprechend vor ('TEXT', 'PASSWORD' und wie sie alle heißen) und kannst dann direkt auf den tatsächlichen Namen in der DB zugreifen. Das ist deutlich übersichtlicher, als eine Zahl, mit der man erstmal so nichts anfangen kann, außer zu raten, welcher Feld-Typ es sein sollte.
Falls du jetzt Bedenken hast, es würde mehr Speicherplatz verbrauchen: Falsch. Letztlich speichert SQL den Zahlenindex der angegebenen Werte und verbraucht nur ein einziges Mal mehr Platz, als deine Lösung. Der Vorteil liegt aber klar auf der Hand

Dann zu deiner Problematik: Sie ist garnicht so trivial, wie du vielleicht vermutest. Was du brauchst ist einfach nur eine Verknüpfung der Tabellen im Stil der Normalform. Was heißt das genau? Das beschreibe ich dir mal eben so kurz ich kann (sorry, wenn es etwas länger wird

Du hast aktuell 2 Tabellen, undzwar einmal die wo die Kategorien drinstehen und eine mit den Features. Um jetzt beliebig viele Features mit beliebig vielen Kategorien zu verbinden erstellst du einfach eine 3. Tabelle!
Du kannst also die `categoryID` aus deiner Features-Tabelle löschen.

Die 3. Tabelle hat dann nur 2 Felder undzwar eins für die UID des Features und eine UID für die Kategorie. Über beide Felder einfach den Primary-Key gelegt und du hast auch keine doppelten Einträge. Die Abfrage ist dann natürlich etwas komplizierter, aber so hast du die Möglichkeit ein Feature keiner, einer oder vielen/allen Kategorie(n) zuzuordnen und umgekehrt. Man nennt das auch eine n:m (sprich: n zu m) Verknüpfung.

Ich hoffe, dass ich dir weiterhelfen konnte!?

[heohni]

Uff, ja.... gut, lass ich mir mal durch den Kopf gehen

[MrNiceGuy]

Wenn du etwas näher umschrieben brauchst, sag es einfach, ich versuche es dann zu beantworten.

[Prophet]

Wenn ich dich richtig verstanden habe sind die Daten der dritten Tabelle doch vollkommen redundant, oder?

[MrNiceGuy]

Zitat von Prophet

Wenn ich dich richtig verstanden habe sind die Daten der dritten Tabelle doch vollkommen redundant, oder?

Das kann garnicht möglich sein, weil ich schrieb, dass die beiden Felder als Primary-Key gesetzt werden sollen, wodurch dann jede Kombination nur ein einziges mal möglich ist. Es würde auch keinen Sinn machen, eine Kombination 2 mal anzulegen. Oder habe ich deine Aussage jetzt falsch verstanden?

[Prophet]

Ich glaube ich missverstehe den Sinn deiner dritten Tabelle...

[MrNiceGuy]

Die 3. Tabelle verknüpft lediglich die anderen 2 Tabellen miteinander, indem es pro Datensatz die UID der einen und die UID der anderen Tabelle beinhaltet. Mehr steht in der Tabelle nicht.