nicht angemeldet
Hi Andreas Korthaus,
Ich muß für eine Anwendung eine dynamische Tabelle haben, soll heißen: Der Anwender kann bei der "installation" eine Tabelle nach seinen Vorgaben erstellen, d.h. Spalten wie er es möchte.
Warum? Dazu solltest Du entsprechende Informationen liefern. Bisher klingt es so, als würdest Du die eierleigende Wollmilchsau programmieren wollen, ohne dies bisher selbst gemerkt zu haben.
Muß der Kunde dabei wirklich die _Namen_ der Spalten beeinflussen können, oder reicht es, wenn er nur die _Datentypen_ (ggf. auch nur von zusätzlichen Spalten über das erforderliche Minimum hinaus) definiert?
- Verwende ich die Tabelle direkt in einer Übersicht, d.h. ich lese in einer Übersicht den Firmennamen aus, und auf einer Unterseite die genauen Daten, wie kann ich es geschickt anstellen, dass ich die Spalte mit dem Firmennamen abfragen kann, wobei ich ja gar nicht direkt weiß wie sie heist?
Genau das mußt Du eben wissen. Cheatah würde Dein Modell grundsätzlich verwerfen ... ich versuche mal, darauf einzugehen, obwohl auch ich es Dir am liebsten ausreden möchte:
Was genau _weißt_ Du während des Konfigurationsdialogs bei der Definition der Tabelle? Das mußt Du Dir dauerhaft merken. Beispielsweise in einer extra-Tabelle, welche Dir eine Abbildung zwischen "semantischen" Spaltennamen (solche, die Du mit bestimmten inhaltlichen Qualitäten verbindest) und "syntaktischen" Spaltennamen (solche, die tatsächlich in SQL-Queries verwendet werden dürfen) liefert. In diesem Falle könntest Du einfach nachsehen, wie Dein Kunde diejenige Spalte genannt hat, welche Deiner Meinung nach eine bestimmte Funktion haben soll. Du müßtest Dir also Deine SQL-Statements erst mal dynamisch ausrechnen.
funktioniert das in der Praxis(Reihenfolge, ungewollte Spalten, schlechte Spaltenbezeichnungen...)?
Es funktioniert schlecht - mit dem oben beschriebenen workaround und beliebigen weiteren denkbaren Problemen. Das ist der Grund, warum Cheatah so etwas grundsätzlich nicht tun würde ... und ich auch nicht. Eine kundenspezifische Anpassung z. B. der Visualisierung hat 'weiter oben' in der Verarbeitungshierarchie zu liegen, finde ich - nicht im Datenmodell selbst.
Und wie verhindere ich am besten dass bei der Installation falsche Spaltennamen verwendet werden?
Indem Du definierst, was 'richtig' bedeutest, und die Eingabe des Kunden zurückweist, falls sie diese Spezifikation nicht erfüllt.
- Problem ist das ich den Firmennamen und die ID manchmal in anderen Teilen in MySQL-Querys brauche. Solte ich vielleicht diese beiden Spalten auf alle Fälle festlegen?
In diese Richtung ging meine obige in Klammern eingeschlossene Anmerkung: Ja, alles festlegen, was der Kunde nicht sinnvollerweise verändern kann. Flexibilität eines Datenmodells ist an sich nicht verkehrt, aber sie kostet etwas - in Deinem Fall ziemlich viel. Ist es das wirklich wert?
Wäre vermutlch eine große Erleichterung, oder wie könnte ich am besten diese Spaltennamen... speichern, so dass ich in der Anwednung darauf zurückgreifen kann, welche Daten welchen Spaltennamen tragen...?
In einer Tabelle. Oder in Kommentarfeldern zu den einzelnen Spalten, falls vorhanden ... das hängt ggf. vom RDBMS ab.
PS: könnte mir XML hier was bringen?
Ohne davon sonderlich viel Ahnung zu haben: Das bezweifele ich. Denn Dein Szenario erscheint mir äquivalent dazu, den Kunden im Dialog eine DTD eingeben zu lassen, ohne daß Dir jemand die Semantik der dort beschriebenen Sprache erklärt hat - das würde das _inhaltliche_ Verarbeiten dieser Sprache ebenfalls sehr erschweren.
Viele Grüße
Michael
T'Pol: I meant no insult.
V'Lar: Of course not. You're simply speaking your mind ... as you always have.