nicht angemeldet
Hi Michael!
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.
Anders herum, darum poste ich hier! Der Anwender soll einne individuellen Fragebogen für seine Lieferanten erstellen können, die Daten jedes Lieferanten sollen dann nach Eingabe in das Forumlar in der Datenbank gespeichert werden. Da die Angaben in diesem Fragenbogen von Firma zu Firma unterschiedlich sind, dachte ich daran eine eigene Tabelle zu verwenden, aber inzwischen ist mir auch klar das das dumm ist, vor allem wenn die eine Datenbank nicht nur von einer Firma genutzt wird, was möglich ist.
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?
Die Datentypen sind eigentlich ziemlich egal(naja, nicht egal, aber eh alles CHAR), das Problem ist das der Kunde diesen Fragebeogen selbst erstellen soll, und das die Felder später im Fragebogen auch Eindeutiog so benannte werden, wie der Kunde das möchte, und nicht so wie ich oder MySQL es möchte. Sicher wäre es für mich einfacher wenn ich einen Standardfragebogen mit festen Feldern machen würde, aber das soll hier halt nicht passieren.
Cheatah würde Dein Modell grundsätzlich verwerfen ... ich versuche mal, darauf einzugehen, obwohl auch ich es Dir am liebsten ausreden möchte:
wieso? Wie soll ich das sonst machen? Zum einen steht die Anzahl der Spalten nicht fest, des weiteren wird sollt eman den Namen/Beschreibung zu einem Feld extra speichen können, um keine Restriktionen unterliegen zu müssen. Also kommt eine einzige Tabelle nicht in Frage, ind auch 2 Tabellen, wo in einer die Daten udn in der andeen die "Feldnamen" stehen funktioniert auch nicht aufgrund der variablen Länge.
Was genau _weißt_ Du während des Konfigurationsdialogs bei der Definition der Tabelle? Das mußt Du Dir dauerhaft merken.
Am liebsten würde ich da nichts wissen, und die komplette Tabelle, bzw. den Fragebogen, komplett frei erstellen lassen. Aber leider muß ich da Einschränkungen machen, da ich in der Anendung an einigen Stellen auf diese So abgefragten Lieferantendaten zugreifen, muß, z.B. diese Lieferantentabelle in einer HTML-Tabelel anzeigen. Oder auch über die Tabelle Joinen, um in einer Auflistung den Lieferanten-Namen stehen zu haben, eine ID alleine ist nicht so schön. Also muß ich im Prinzip diese beiden Felder festlegen, ID und Firmenname. Ach ja, und email auch noch! Am besten sollte ich dann glaube ich alles was soweiso überal ungefähr gleich ist standardmäßig vorgeben, also Firma, Adresse, Ansprechpartner. Den Rest muß man sich dann mittels eines kleinen "generators" selbst bauen. Die fest stehenden Felder kämen dann in eier Lieferanten-Tabelle, dann gäbe es noch eine Individuelle_lieferanten_spalten-Tabelle, in der dann jeweils
Feld_ID
Lieferanten_ID
Feldname
Feldtyp
stehen müßte
und noch eine Tabelle Individuelle_lieferanten_daten mit
Feld_ID
wert
was anders fällt mir hier nicht ein.
Ein ganz anderer Ansatz wäre es, das man in einem völlig freien Generator die 3 Pflichfelder selbst zuweisen muß, das heißt der Kunde baut ale Flder selbst, und muß dann angeben in welchem Feld der Name und in welchem die email-Adresse steht. Aber das ist dann wiedr doof wenn ich z.B. die Adresse eines Lieferanten anzeigen will, oder den Ansprechpartner, also müßte ich schon alle allgemeinen Felder so zuweisen, aber das kann es eigentlich auch nicht sein. Ich frag mich wie andere sowas lösen, denn das habe ich schön öfter gehört bzw. gesehen, weiß nur nicht mehr wo und wie das genau gelöst war.
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.
Das löst aber noch nicht das Problem mit der variablen Tabellenlänge.
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 soll ich das machen? Die Visualisierung ist ein Web-Forntend was mit HTML/PHP/MySQL realisiert wird. "Wo soll ich da noch eione andere Visualisierung herbekommen?"
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?
Es ist eine Vorgabe. Außerdem muß das ganze nicht besonders performant ein, wenn das das Problem sein sollte. Die SAche soll nunmal recht flexibel sein. ODer vielleicht ist doch der "eigene Tabellen" Ansatz der richtigere, denn es werden sowieso niemals besonders viele Kunden in einer DB sein, _allerhöchtens_ 100, eher erheblich darunter. Der Normalfall ist 1 Kunde, aber da das ganze auch als ASP Lösung angeboten werden soll, können das auf dem eigenen Server schonmal ein paar mehr Kunden werden. Zur Not brauche ich eine eigene Datenbank für jeden Kunden.
In einer Tabelle. Oder in Kommentarfeldern zu den einzelnen Spalten, falls vorhanden ... das hängt ggf. vom RDBMS ab.
MySQL hat sowas IMHO nicht, oder?
Viele Grüße
Andreas