nicht angemeldet
Tach!
BUILDER_INQUIRY besitzt einen reply_type (input, multiple_choice, etc). Anhand diesen könnte ich dann in der Anwendung die entpsrechende Referenztabelle joinen.
Was du joinen musst, weißt du erst, wenn du die Werte aus der einen Tabelle kennst. Du kannst nicht von Fall zu Fall zu jedem Datensatz einzeln eine andere Tabelle joinen. Das heißt, du kannst gar nicht joinen, oder für jeden Typ eine eigene Query erstellen. Was fragst du denn für Daten ab? Eine Frage und deren Antworten oder mehrere Fragen und deren Antworten? In beiden Fällen wäre zunächst die eine Tabelle zu befragen und dann passend die anderen Tabellen. Nur bei mehreren kann man dann eventuell noch was optimierne, indem man die Antworttypen zusammenfasst und dann gemeinsam deren Antworten abfragt.
Mir ist der Anwendungsfall irgendwie zu flexibel um ihn normalisiert zu halten.
Daher meine Frage, ob in diesem Fall nicht evtl. zu einer NoSQL-Datenbank zu raten wäre.
Du siehst hier, es ist mit einigen Kopfständen verbunden, zu einer RDBMS-Lösung zu kommen (oder es gibt einen Weg, der mir grade nicht einfällt). Jedenfalls wäre hier wohl besser, die Antwortmöglichkeiten in einer anderen passenderen Struktur (verschachtelte Arrays, Objektgebilde) anzulegen und diese zu serialisieren. Ein RDBMS bringt dir hier wohl keinen Vorteil, weil du in den Antworten sicherlich nicht mit den Funktionen des DBMS suchen möchtest. Auf NoSQL umzusteigen muss auch nicht unbedingt sein, ein Serialized-LOB-Feld (also serialisierte Antworten-Gebilde) täte es im Prinzip auch.
dedlfix.