Mailinglisten-Archive |
Hallo Kurt (oder Rene?), > -----Original Message----- > From: Kurt Rene [mailto:rene.kurt at planet-web.ch] > (...) > vergessen haben kann, daher suche ich nach einer möglichkeit die struktur > der tabellen mit unterschiedlichen daten (jeder anwender hat die seinen) > gleich zu halten. > kann mir jemand einen denkanstoss geben, so dass ich mal in die richtige > richtung suchen kann? Mit den Änderungen ist es Sinnvoll eine Versionstabelle in der DB zu halten, die je Tabelle den aktuellen Versionsstand meldet. Die Tabellenänderungen werden dann als Alter Table (nicht Alter Ego) ausgeführt und zwar ausgehend von der aktuellen Version. Jeder Versionsstandswechsel je Tabelle oder DB ist dabei in einem SQL-Script abgelegt. Die Scripte müssen dann beim Update von einem kleinen Programm abhängig von der aktuellen Version "inkrementell" eingespielt werden. Zur restlichen Organisation sehe ich zwei Möglichkeiten. Zwei Möglichkeiten. a) Du machst 2 Tabellen, in Tabelle 1 die Stammdaten, die Du pflegst in Tabelle 2 die Daten die der Anwender frei bestimmen kann. Beide Tabellen sind über den Primärschlüssel 1:1 verbunden. b) Sämtliche benutzerdefinierten Felder sind in einer Feld-Tabelle abgelegt. Dazu gibt es dann noch eine Schlüsseltabelle. Also: Schlüssel-Tab: Schlüssel-Id Feldname Feldtyp evtl. Sortierreihenfolge Feld-Tab: Primärschlüssel-Stammsatz (Referenz auf Stammsatz) Schlüssel-Id Feldwert (z.B. in Varchar) Nachteil von b) Du mußt die Typen selbst abbilden bzw. von/in Varchar konvertieren und die Verwaltung ist evtl. etwas schwieriger. Außerdem ist natürlich die Performance etwas schlechter. Dafür wurschteln Dir die Leute nicht in der DB-Definition herum. Grüße, Michael Donning -- Infos zur Mailingliste, zur Teilnahme und zum An- und Abmelden unter -->> http://www.4t2.com/mysql
php::bar PHP Wiki - Listenarchive