nicht angemeldet
Dynmaische Tabellenstruktur -> create View
Hallo zusammen,
ich 2 Tabellen.
in der ersten Tabelle DYN ist die Feldbeschreibung z.B.:
Satz1:
ID = 1
Feldanzeige = Strasse
Tabelle = Daten1
Feld = WERT1
Feldlänge = 25
---------
Satz2:
ID = 2
Feldanzeige = Ort
Tabelle = Daten1
Feld = WERT2
Feldlänge = 20
....
Die Tabelle Daten1 sieht z.B. so aus:
Wert1 = Haupstr.
Wert2 = Berlin
Wert3
....
Nun möchte ich eine View machen die mir dieses Ergebnis ausgibt
Strasse, Hauptstr.
Ort, Berlin
Das ganze geht natürlich noch etwas tiefer. Mir fehlt jedoch erstmal als Startup ein Lösungsansatz wie ich dynmaisch die Felder aus der einen Tabelle in die andere in der View übergebe. Hat jemand einen Tip?
Das ganze unter MySQL 5.1.
Vielen Dank im voraus.
Grüsse
Matthias
-
Hallo,
ich staune, dass noch niemand geantwortet und sich den Mund über etwaiges miserables physikalisches Design deiner Datenbank zerissen hat.
Ich tue es auch nicht, aber dennoch würde ich dir anraten, dieses physikalische Design deiner Datenbank mal zu überdenken, so ganz koscher (i.e. zweckmäßig) scheint es mir nicht zu sein.Deine Problemstellung ist imho in der Tat nicht ganz trivial. Was du machen möchtest, Zeilen zu Spalten transponieren bzw. pivotieren?!
PIVOT ist das Stichwort, nachdem du vielleicht einfach mal im Handbuch zu deinem MySQL 5.1 suchen solltest. Manche DBMSse haben so eine Funktion eingebaut.
Wenn du endlich viele (bzw wenige) Möglichkeiten abdecken musst, wie eben Adressen, dann käme vielleicht in Frage oft genug Self-JOIN(T)s zu drehen äh machen.
Ansonsten würde ich eher eine Stored Procedure empfehlen, die eine Temporäre Tabelle anhand der Vorgaben für die gewünschten "Feldanzeigen" erstellt und mittels mehrerer Abfragen auf die Quelltabellen diese temporäre Tabelle füllt und am Ende als Resultset zurückgibt. MySQL 5.1 sollte die Möglichkeit für Stored Procedures mitbringen.
Adios,
Frank-
Hallo zurück,
ich staune mit. Ich hätte nicht gedacht, dass man mit einem beispielhaften Design zerrissen werden kann.
Ich möchte an dieser Stelle nur das Stichwort generisches DB-Design nennen. Ist es überhaupt meins? Fragen über Fragen :-).Aber wie auch immer. Ich denke auch der einzig vernünftige Weg für dieses Problem sind Stored Procedures.
An der Stelle für alle, die es auch interessiert unten ein Link.
Und natürlich danke für Deine Antwort.Matthias
-
Hoi,
mit einem beispielhaften Design
Woran hast du dir ein Beispiel genommen und warum meinst du, dass dieses Beispiel so geeignet wäre? An die ersten Grenzen (wie transponiere ich Zeilen in Spalten für meine Ausgabe) bist du ja bereits gestossen.
Ich möchte an dieser Stelle nur das Stichwort generisches DB-Design nennen. Ist es überhaupt meins?
Wenn du eine Frage dazu stellst und keine weiteren Infos gibst, das liegt das für den allgemeinen Leser relativ nahe, dass du eng in Verbindung mit dem Design stehst, "es deines ist".
Aber wie auch immer. Ich denke auch der einzig vernünftige Weg für dieses Problem sind Stored Procedures.
Hast du das schon vorher gewusst?
Sicher ist eine SP im gegebenen Anwendungsfall das probateste Mittel, aber nach einem kurzen Blick in den Code sehe ich "CURSOR". Cursors bedeuten datensatzweise Verarbeitung was den Vorteil von Mengenoperationen (Mengen, die mit SQL genau beschrieben werden können und was dann effizient umgesetzt werden kann) auf fast 0 reduziert.
Aber der Zweck heiligt die Mittel. :)
Viel Glück.
Frank-
Moin Frank,
für mich ist der Sinn von Foren auch mal einen anderen Denkansatz zu erhalten.
Hast du das schon vorher gewusst?
Also ja, wusste ich. Aber vielleicht wollte sich mein inneres auch einfach vor SP drücken.
Aber der Zweck heiligt die Mittel. :)
Dem kann ich nur völlig zustimmen.
Viel Glück.
Danke wer kann das nicht brauchen.
Und Dir wünsche ich schonmal ein schönes Wochenende.
Matthias
-
-
-