Datenbank mit Dynamischen Spalten

[sebi87]

Hallo Leute,

ich möchte/muss meine Datenbank ziehmlich dynamisch halten. Hierraus ergibt sich die Schwierigkeit das ich Spalten vom Typ SMALLINT erzeugen und löschen können muss.

Wie kann ich das Per SQL lösen ohne einen DB-Editor benutzen zu müssen?



Danke

Sebastian

[WIng2005]

Mahlzeit,

meines Wissens nach kannst du Felder mit

Delphi-Quellcode:

ALTER TABLE name ADD feldname typ

anghängen und löschen mit

Delphi-Quellcode:

ALTER TABLE name DROP feldname

...hoffe mal das hilft...

MFG
Steffen

[sebi87]

soweit ganz gut. Wenn ich wie beschrieben eine Spalte anhängen will bekomme ich die Fehlermeldung:

Zitat:

SQL Error: unsuccessful metadata update STORE RDB$RELATION_FIELDS failed no permission for control access to TABLE CUSTOMER. Error Code: -607. This operation is not defined for system tables. Rhe SQL: ALTER TABLE CUSTOMER ADD K030 SMALLINT DEFAULT -1 ;;

Was mache ich falsch??

[WIng2005]

"no permission for control access to TABLE CUSTOMER" -> fehlen dir evtl. die Berechtigungen?


MFG
Steffen

[sebi87]

Wie müssen die Berechtigungen zum erstellen einer neuen Spalte sein??

Ich habe auf der Tabelle alle Rechte. Darf also prinzipiell alles machen. Kann es mit dem Eigentümer der Tabelle zu tun haben?


Grüßle

Sebastian

[Sherlock]

Dynamische Datenbanken sind fürchterlich unperformant. Überleg Dir grundsätzlich, ob das wirklich so sein muss.

Sherlock

[sebi87]

Also dazu kann ich nur sagen das wir, also ich und mein Mitentwickler uns das 2 Monate überlegt haben und wir zum Entschluss gekommen sind das das die eizig sinnvolle und am einfachsten zu handhabende Lösung ist.


Das ganze hat auch schon funktioniert, als das System noch mit einer Access Datenbank lief. Jetzt haben wir das ganze auf Firebird umgestellt und wir haben das Problem, dass das erstellen und löschen von Spalten nichtmehr funktioniert.

Grüßle

Sebastian

[sebi87]

Hab das ganze jetzt mal als SYSDBA versucht und siehe da es funktioniert.

Als User habe ich die gleichen Rechte wie SYSDBA.
Der Owner der Tabelle ist allerdings SYSDBA.
Kann ich eine Tabelle nur ändern wenn ich auch der Owner bin???

Wie kann ich das lösen das ich von jedem User mit den schreibrechten die Tabelle ändern kann?


Grüßle
Sebastian

[Billa]

Was spricht gegen eine zweite Tabelle, in der eben keine weiteren Spalten, sondern Sätze gespeichert sind? Ist auch performant und vermeidet dauernde Änderungen an der Datenstruktur ...

[sebi87]

Ihr hab schon recht, das ändern der Datenstuktur ist nicht optimal, aber das Problem ist das sich sowohl Spalten und Zeilen ändern.

Ich weiß keine andere Lösung wie ich es anstellen soll, dass ich eine Martix habe das sich in 2 Dimmensionen ändern kann und ich in jedes Feld einen Eintrag schrieben kann.

Wenn jemand eine Andere Lösung hat bin ich dankbar.

Aber das hat mein Problem noch nicht gelöst.


Grüßle
Seabstian

[Billa]

Ich denke mir das so:

Tabelle1 (die "Zeilen" Deiner Matrix)

T1_ID
T1_Feld1
T1_Feld2 (eben alle Felder, die immer vorkommen)


Tabelle2 (die "Spalten"..)
T2_ID
T2_FK_T1 (Verweis auf die Zeile, z.B. mit Foreign Key Constraint auf T1_ID)
T2_Wert

jetzt kannst Du in "zwei Dimensionen" beliebige Zeilen und Spalten anlegen.
Wenn Du eine neue Spalte brauchst, legst Du also einfach statt neuer Spalten
in T1 neue Sätze in Tabelle2 an. Pro Zeile aus Tabelle 1 ein neuer Satz in
Tabelle2 mit der entsprechenden Zeilen-ID (T1_ID) der Zeile in T2_FK_T1.

Es existieren also in Tabelle2 AnzahlZeilen*AnzahlSpalten Sätze...

Damit hast Du Änderungen an der Struktur durch einfache Satzoperationen ersetzt.
Absolut flexibel. Wenn Du noch eine dritte Dimension benötigst, gibt es halt nach
gleichem Schema eine dritte Tabelle.... (Stichwort Normalisierung)

[Billa]

äh... man sollte in Tabelle2 noch eine Feld T2_Spaltennummer mitführen, dann sind auch Operationen unabhängig von der Zeile möglich....

[sebi87]

Ich kann mir das irgedwie nicht so vorstellen wie ich das dann erstellen muss...

kannst du mir da irgendwie ein Beispiel mit zwei Tabellen zeigen?

[Billa]

Du hast das Stichwort Matrix doch selbst gegeben.
Angenommen Du hast eine Tabelle mit 4 Zeilen und 4 Spalten

1 2 3 4

5 6 7 8

9 10 11 12

13 14 15 16

Wie adressierst Du einen bestimmten Wert? Indem Du Zeilennummer und Spaltennummer angibst.
Für die 11 z.B. "3" und "3" (oder 2/2 wenn Deine Zählung bei 0 beginnt)
Schau Dir Tabelle2 (mit der Spaltennummer) nochmal an. Da hast Du die Felder
T2_FK_T1 ("Zeilennummer") und T2_Spaltennummer. Die geben Dir Position in der Matrix.
Du speicherst also in einem Satz nicht nur den Wert, sondern auch seine Adresse.

Im Extremfall kannst Du also sogar auf Tabelle1 verzichten, nämlich wenn es keine Informationen außer dem Wert selbst gibt. Mit Tabelle1 ist es aber schicker, weil Du Zusatzinformationen zu einer Zeile ohne Redundanzen speichern kannst.

Wie das konkret aussieht, hängt von Deiner Datenbank bzw. Deiner Anwendung ab. Das hier ist nur
ein "Kochrezept"....

[alzaimar]

Wir haben ein solches System für eine polymorphe Produktdatenbank. Dort gibt es Produktklassen (z.B. Fernseher, Schrauben, Delphi-Updates etc.). Jede Produktklasse hat ein eigenes 'Tabellenlayout'. Um nun alle unterschiedlichen Produkte unter einen Hut (sprich Datenbank) zu bringen, haben wir ein Konzept implementiert, das dem von billa ähnelt. Natürlich haben wir noch unterschiedliche Datentypen, sowie Formatanweisungen, Einheiten ('m','mm','V' etc.), in einer separaten Tabelle, und jeder 'Spaltenwert' enthält zusätzlich noch die ID der Spaltendefinition.

Für jede Produktklasse haben wir zudem eine View 'View_<Produktklasse>', sodaß man schnell auf die 'Tabelle' zugreifen kann. Jede Änderung am "Tabellenlayout" einer Produktklasse erzeugt per Trigger eine neue View.

Über die INSERT/UPDATE/DELETE-Trigger der View realisieren wir Datenmanipulationen, sodaß unsere Metadaten nach außen hin völlig transparent sind. In der Tat haben alle Produktfamilien einige Eigenschaften gemein, z.B. Produktnummer, Version, Name, Beschreibung, Gültigkeitszeiraum etc., sodaß wir über ein

SQL-Code:

select * from View_AlleProdukte

alle Produkte anzeigen können.

Wir haben über die Jahre die Erfahrung gemacht, das das eine sehr einfache und komfortable Art und Weise ist, mit sich dynamisch ändernden und polymorphen Daten zu arbeiten.

[sebi87]

Hmm...
Ich werde mir das nochmal anschauen.
Danke mal für die Lösungsvorschläge.


Grüßle
Sebastian

[Phoenix]

Ganz andere Idee:

tblMatrix:
PK ID, FK ReferenzId, Column, Row, Value

ReferenzId zeigt auf den Datensatz, zu dem diese Matrix gehört.

Die Werte der Matrix sind mit ihrem Wert in Column und Row adressiert.
Zeile löschen: Delete from tblmatrix WHERE ReferenzId = Datensatznummer AND Row = Zeilennummer
Spalte löschen: Delete from tblmatrix WHERE ReferenzId = Datensatznummer AND Column = Zeilennummer

Edit Nachtrag: So beim durchlesen fällt mir ein, das Billa das schon Vorgeschlagen hatte... Man bin ich langsam heut :-o

[sebi87]

Vielen Dank für die zahlreichen Ideen.

Hab es jetzt so gelöst wie Billa vorgeschlagen hat und es funktioniert wirklich gut.


Grüßle

Sebastian