dynamische Datenbank-Tabelle

[Andreas Korthaus]

Hallo!

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. Die Tabelle enthält Lieferantendaten, die je nach Unternehmen verschieden gespeichert werden, durch individuelle Qualifizierungs-Merkmale der Lieferanten.
Dabei habe ich 2 Probleme:
1. Verwende ich die Tabelle direkt in einer Übersicht, d.h. ich lese in einer Übersicht denFirmennamen aus, und auf eien Interseite 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? Das selbe bei dem kompletten Formular, ich kann zwar die Daten in einer Schleife auslesen und den Spaltennamen als Beschreibung vor jede Angabe setzen, aber funktioniert das in der Praxis(Reihenfolge, ungewollte Spalten, schlechte Spaltenbezeichnungen...)? Und wie verhindere ich am besten dass bei der Installation falsche Spaltennamen verwendet werden?
2. 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? 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...?
Hab sowas noch nie gemacht, wenn emand einen Tipp hat bin ich sehr dankbar!

Viele Grüße
Andreas

PS: könnte mir XML hier was bringen?

[Cheatah]

Hi,

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. Die Tabelle enthält Lieferantendaten, die je nach Unternehmen verschieden gespeichert werden, durch individuelle Qualifizierungs-Merkmale der Lieferanten.

das nennt sich n:m-Beziehung. Das, was Du im Moment als Spalten ansiehst, werden Datensätze einer weiteren Tabelle. Die Verknüpfungen zwischen beiden bestehenden Tabellen werden durch eine dritte geregelt, Kreuztabelle genannt.

1. Verwende ich die Tabelle direkt in einer Übersicht, d.h. ich lese in einer Übersicht denFirmennamen aus, und auf eien Interseite 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?

Das Layout der Tabellen ist Dir _immer_ bekannt. Ansonsten hast Du Probleme. Überlasse es keinem Fremden, besonders keinem Kunden, das Tabellenlayout mitzubestimmen.

PS: könnte mir XML hier was bringen?

Da Du Datenbank-Inhalte als XML exportieren[1] und XML-Daten in ein DB-Layout umwandeln kannst, darfst Du Dir aussuchen, ob Du Deine Spaltennamen als Tabelleninhalte oder als Attributwerte haben möchtest.

Cheatah

[1] Wenn Du es geschickt machst, versteht sich. Im Gegensatz zu DB-Beziehungen ist bei XML eine unendliche Schachtelung recht schwierig. Auch in XML lässt sich Redundanz jedoch vermeiden.

[Andreas Korthaus]

Hallo Cheatah!

das nennt sich n:m-Beziehung. Das, was Du im Moment als Spalten ansiehst, werden Datensätze einer weiteren Tabelle. Die Verknüpfungen zwischen beiden bestehenden Tabellen werden durch eine dritte geregelt, Kreuztabelle genannt.

gut das Du mich dran erinnerst, ich hatte gar nicht an den Fall gedacht, das auf einem System evtl die Anwendung mehr als einmal laufen könnte. Denn dann klappt es nicht mehr so gut mit veränderbaren Tabellen. Die von dir geschilderte Variante verwende ich dort schon mehrfach, aber hier ist das evtl. etwas problematisch: das ist die einzige Tabelle die veränderbar sien soll. Das das doof ist habe ich gemerkt, aber ob jetzt mit einem alter-table Statement, oder mit aktualisierungs-Abfragen in Deiner Spalten-Tabelle, das Problem ist und bleibt dasselbe:
Die Inhalte, das gesamte Layout der Tabelle sind nicht 100% genau definiert. Das _soll_ so sein, nur doof das ich die Daten dann woanders brauche. Deshalb mußt ich irgendwie die Spalten die ich definitiv brauche vorgeben, und nur den Rest der Tabelle dynamisch gestalten, nur weiß ich halt noch nicht so ganz wie man das praktisch machen soll.
Ich könnte da sja so machen:

Tabelle Liefreanten:
 id
 firmenname

Tabelle Lieferanten-Spalten:
 id
 lieferanten_id(mit Tabelle Lieferanten verknüpft)
 spaltenname

Tabelle Lieferanten-Daten
 id
 spaltennamen-id(mit Tabelle Lieferanten-Spalten verknüpft)
 wert

Ich schreibe Grundsätzlich den Eintrag ID und Firmenname vor, der Rest wird vom Kunden als Datensatz eingetragen. ODer meinst DU ich sollte auf die erste Tabelle verzichnten und alles mit diesen n:m Beziehungen schreiben?

1. Verwende ich die Tabelle direkt in einer Übersicht, d.h. ich lese in einer Übersicht denFirmennamen aus, und auf eien Interseite 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?

Das Layout der Tabellen ist Dir _immer_ bekannt. Ansonsten hast Du Probleme. Überlasse es keinem Fremden, besonders keinem Kunden, das Tabellenlayout mitzubestimmen.

Hier ist es aber explizit gefordert, was ja nicht heißt das der Kunde tatsächlich so eine eigene Tabelle hat, es muß nur so aussehen und funktionieren.
Mit Deiner Variante sollte doch auch das Problem mit den ungültigen Spaltennamen erledigt sein!

Grüße
Andreas

[Cheatah]

Hi,

das nennt sich n:m-Beziehung. [...]
[...] das ist die einzige Tabelle die veränderbar sien soll.

ja, das nennt sich n:m-Beziehung ;-)

Ernsthaft: Ein DB-Layout dynamisch zu halten ist nicht wirklich gut[tm]. Überlege Dir, welche änderbaren Details die Tabelle haben soll (z.B. n Spalten, davon jeweils Name und Typ beliebig), hinterlege diese Informationen in einer Tabelle (CREATE TABLE spalten (id, name, typ), sinngemäß, ähnlich Deinem Vorschlag weiter unten), referenziere in einer Inhalts-Tabelle auf spalten.id. Wenn es mehrere solcher Tabellen geben soll, gibt's in 'spalten' noch eine Spalte mehr - naja, Du weißt schon was ich meine.

Die Inhalte, das gesamte Layout der Tabelle sind nicht 100% genau definiert. Das _soll_ so sein,

Nein, soll es nicht :-) Das Layout sollte fest sein, aber eben so flexibel, dass die Anforderungen, welche zu dieser Forderung fehlinterpretiert wurden, erfüllbar sind.

Ich könnte da sja so machen:

Jupp.

ODer meinst DU ich sollte auf die erste Tabelle verzichnten und alles mit diesen n:m Beziehungen schreiben?

Die Details der Lösung hängen von den Details der Anforderung ab. Grundsätzlich sind viele Wege möglich; man sollte aber tunlichst einen wählen, bei dem sich das DB-Layout nicht ständig verändert.

Das Layout der Tabellen ist Dir _immer_ bekannt. Ansonsten hast Du Probleme. Überlasse es keinem Fremden, besonders keinem Kunden, das Tabellenlayout mitzubestimmen.
Hier ist es aber explizit gefordert, was ja nicht heißt das der Kunde tatsächlich so eine eigene Tabelle hat, es muß nur so aussehen und funktionieren.

Exakt :-)

Mit Deiner Variante sollte doch auch das Problem mit den ungültigen Spaltennamen erledigt sein!

Jupp, Du hast hier sogar die Möglichkeit selbst zu definieren, was als gültig gelten soll und was nicht. Wenn Du lustig bist, kannst Du als Spaltennamen auch den Inhalt einer Grafik zulassen ;-)

Cheatah

[Michael Schröpl]

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?

1. 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.

2. 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

[Andreas Korthaus]

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

[Michael Schröpl]

Hi Andreas,

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.

_das_ wäre noch gar nicht mal das Problem: In mySQL kannst Du beliebig viele "Datenbanken" anlegen, welche dann als Container Tabellen mit beliebigen Namen (auch gleichnamige in verschiedenen "Datenbanken" enthalten können. Sprich: Jede Instanz Deiner Anwendung arbeitet dann in ihrer "Datenbank", kann dort aber Tabellen ihrer Wahl anlegen.

Ich habe beispielsweise eine Suchmaschine, die in einer Instanz aktiv läuft und dabei auf eine Datenbank zugreift. Welche Datenbank das gerade ist, findet die Suchmaschine heraus, indem sie auf der Festplatte aus einer Datei ein Bit liest.
In der jeweils anderen der beiden Datenbanken baut im Hintergrund ein Importprozeß die nächste "Version" der zu durchsuchenden Daten auf ... und wenn er fertig ist, dann schaltet er die Datei um. Jeder CGI-Aufruf greift also auf _irgend_ eine der beiden Datenbanken zu ... und mein Programm ist 24 Stunden verfügbar, obwohl es sehr wohl eine housekeeping-Phase benötigt.

Die Datentypen sind eigentlich ziemlich egal(naja, nicht egal, aber eh alles CHAR),

Dann kannst Du also alles durch ein hinreichend langes VARCHAR darstellen? Fein.

Definiere Dir eine Tabelle der Forum [kundenname, fragebogenid, feldname, feldwert], und Du kannst beliebige Fragebogen speichern. Reicht das? Niemand zwingt Dich dazu, die Felder des Fragebogens als Spalten zu definieren - das können auch Zeilen sein. Und dann bist Du sehr flexibel ...

Viele Grüße
      Michael

[Andreas Korthaus]

Hallo!

Die Datentypen sind eigentlich ziemlich egal(naja, nicht egal, aber eh alles CHAR),

Dann kannst Du also alles durch ein hinreichend langes VARCHAR darstellen? Fein.

warum VARCHAR? Warum schön? Weil CHAR mit Länge 255 zu viel Platz wegnimmt?

Definiere Dir eine Tabelle der Forum [kundenname, fragebogenid, feldname, feldwert], und Du kannst beliebige Fragebogen speichern. Reicht das? Niemand zwingt Dich dazu, die Felder des Fragebogens als Spalten zu definieren - das können auch Zeilen sein. Und dann bist Du sehr flexibel ...

Meisnt Du auch den "Feldnamen" in jeden Datensatz? Bei einigen 100 Lieferanten pro Kunde ist dann aber sehr viel Text umsonst drin! Sollte man die Feldnamen nicht mit einer ID versehen und in einer eigenen Spalte ablegen, und dann nur die Feldnamen-ID in "Deiner" Tabelle speichern? Udn auch keien "doppellösung" mit einer echten Tabelle "Lieferanten", und nur mit den tatsächlich notwendigerweise flexiblen Feldern in eienr flexiblen Struktur wie von Dir beschreiben? Bedenke das ich an einigen Stellen auf Werte aus der Tabelle zugreifen muß, auf die "Statischen", und auch darüber joinen will, das wird mit so einer Tabelle wie von Dir geschreiben würde erheblich schwieriger! Udn was spräche gegen eine "echte" eigene Tabelle, wenn das doch nicht mehr als 100 Stück werden wäre das aber die wohl sauberste und schnellste Lösung, wobei das natürlich gegen viele "Relationale Datenbank"-Grundsätze verstößt, aber kann man denn nicht heir mal ein Auge zudrücken? Was ist denn so schlect daran? Wo ist da ein Nachteil? Nur das es unübersichtlicher wird, und weil bei 10.000 Tabellen Probleme auftreten, oder weil es sich "nicht gehört"?

Grüße
Andreas

[Michael Schröpl]

Hi Andreas,

Dann kannst Du also alles durch ein hinreichend langes VARCHAR darstellen? Fein.
warum VARCHAR? Warum schön? Weil CHAR mit Länge 255 zu viel Platz wegnimmt?

CHAR oder VARCHAR ist mir an dieser Stelle egal - es reicht, wenn der Kunde nicht die Datentypen angeben darf. Denn so behältst Du die Kontrolle über Dein CREATE TABLE-Statement.
Ich denke aber, daß Du wahrscheinlich mit ca. 30 Zeichen pro Feld auskommen könntest (das wäre Faktor 10 gegenüber den genannten 256 Byte); dafür darf der Kunde ja beliebig viele Felder definieren ...

Definiere Dir eine Tabelle der Forum [kundenname, fragebogenid, feldname, feldwert],
Meint Du auch den "Feldnamen" in jeden Datensatz?

Ja.

Bei einigen 100 Lieferanten pro Kunde ist dann aber sehr viel Text umsonst drin! Sollte man die Feldnamen nicht mit einer ID versehen und in einer eigenen Spalte ablegen, und dann nur die Feldnamen-ID in "Deiner" Tabelle speichern?

Hm ... kannst Du auch probieren, aber ich denke, so arg viel Unterschied wird das gar nicht machen.
Laß es mal Faktor 2 für die gesamte Tabelle sein - auf der anderen Seite hättest Du dann einen JOIN mehr. Lohnt sich das insgesamt? Du kannst Deinem Kunden vorgeben, daß Feldnamen eine Maximallänge von 16 oder 32 Zeichen oder so ähnlich haben dürfen - viel mehr wird er kaum brauchen. Der Feldwert wird jedenfalls länger sein als der Feldname - insofern ist das Einsparungspotential begrenzt.

Beim "kundenname" sehe ich Dein Argument schon weitaus eher ein ... da ist eine ID sinnvoll. (Du wirst einen PRIMARY KEY über die ersten drei Spalten haben wollen.)

Bedenke das ich an einigen Stellen auf Werte aus der Tabelle zugreifen muß, auf die "Statischen", und auch darüber joinen will, das wird mit so einer Tabelle wie von Dir geschreiben würde erheblich schwieriger!

Wieso? Statt mit der Spalte "preis" JOINst Du dann halt mit der Spalte "feldwert" aus der Tabelle, wo Du die Zeilen mit WHERE feldname="preis" selektiert hast. Wo ist der Unterschied?
Du mußt dann halt die JOINs explizit hinschreibern (WHERE a.feldname=b.feldname) und auf diese proprietären Kurznotationen wie LEFT JOIN verzichten.

Und was spräche gegen eine "echte" eigene Tabelle, wenn das doch nicht mehr als 100 Stück werden

Daß Du einen viel aufwändigeren SQL-Code-Generator brauchst, der schwerer zu pflegen ist. Das ist Dir ja auch bewußt geworden, denke ich.

wäre das aber die wohl sauberste und schnellste Lösung, wobei das natürlich gegen viele "Relationale Datenbank"-Grundsätze verstößt,

Genau deshalb ist es nicht "sauber". ;-)

aber kann man denn nicht heir mal ein Auge zudrücken? Was ist denn so schlect daran? Wo ist da ein Nachteil? Nur das es unübersichtlicher wird, und weil bei 10.000 Tabellen Probleme auftreten, oder weil es sich "nicht gehört"?

"Unübersichtlich" finde ich am schlimmsten. Denn das ist eine Rechnung, die Du persönlich bezahlen mußt, bei der Pflege Deines Codes.

Viele Grüße
      Michael