dynamische Datenbank-Tabelle

[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