nicht angemeldet
MySQL 5: Felder updaten, die es nicht gibt
Hallöle,
vielleicht kennt ihr das Problem: Mehrere Projekte, die neueren haben zusätzliche Felder in den Tabellen.
Nun schiebt man die aktuelle Programmversion auf das alte Projekt und - peng - Datenbank- Fehler beim UPDATE, weil das Programm ein Feld anspricht, das die alte Tabelle nicht hat und auch nicht braucht.
Kann man der Datenbank irgendwie sagen: Ignoriere diesen Fehler, fülle die Felder, die da sind?
Beim Lesen geht's doch auch, wenn ein Feld nicht da ist, ist der Inhalt NULL.
Lieben Gruß, Kalle
-
Hi Kalle_B,
du kannst default Werte angeben.
MfG
Otto-
du kannst default Werte angeben.
Das ist ein anderer Fall, wenn du in der Tabelle *mehr* Felder hast, als vom Programm angesprochen werden.
Ich habe aber *weniger*
LG Kalle
-
-
Hallo Kalle,
vielleicht kennt ihr das Problem: Mehrere Projekte, die neueren haben zusätzliche Felder in den Tabellen.
Nun schiebt man die aktuelle Programmversion auf das alte Projekt und - peng - Datenbank- Fehler beim UPDATE, weil das Programm ein Feld anspricht, das die alte Tabelle nicht hat und auch nicht braucht.
das löst man typischerweise mit entsprechenden ALTER-Scripten, die die Datenbank aktualisieren. Diese gehören mit in die Versionskontrolle.
Freundliche Grüße
Vinzenz
-
Hallo Vinzenz,
das löst man typischerweise mit entsprechenden ALTER-Scripten, die die Datenbank aktualisieren. Diese gehören mit in die Versionskontrolle.
Hmm, nicht das, was mir vorschwebt. Möchte das mal mit einem konstruierten Beispiel verdeutlichen:
Der Fahrradhändler hat eine Tabelle mit den Fahrrad- Bestandteilen. Sitz, Lenker, Gangschaltung, Licht vorn und hinten.
Die neue Version ist für den Autohändler, also kommt Kofferraumdeckel, Ersatzreifen, Schiebedach dazu.
Die Fahrradhändler- Version wird diese Felder niemals benötigen. Wie erzeugt man Programmkompatibilität bei verschieden ausgeprägten Tabellen?
Ich weiss, Feldnamen einlesen usw. Dachte nur, es ginge unkomplizierter.
Kalle
-
Moin!
»» das löst man typischerweise mit entsprechenden ALTER-Scripten, die die Datenbank aktualisieren. Diese gehören mit in die Versionskontrolle.
Hmm, nicht das, was mir vorschwebt. Möchte das mal mit einem konstruierten Beispiel verdeutlichen:
Der Fahrradhändler hat eine Tabelle mit den Fahrrad- Bestandteilen. Sitz, Lenker, Gangschaltung, Licht vorn und hinten.
Die neue Version ist für den Autohändler, also kommt Kofferraumdeckel, Ersatzreifen, Schiebedach dazu.
Dann ist das keine neue Version, sondern eine ANDERE.
Wenn es also überhaupt Sinn ergibt, solche speziellen Feldnamen zu nutzen (das sollte bei vernünftiger Normalisierung bzw. vernünftiger Generalisierung des Problems nicht auftreten), dann muss man damit leben, dass man unterschiedliche Versionen pflegen muss.
Die Fahrradhändler- Version wird diese Felder niemals benötigen. Wie erzeugt man Programmkompatibilität bei verschieden ausgeprägten Tabellen?
Indem man im DB-Access-Layer weiss, was man in die DB schreiben kann, und was nicht.
- Sven Rautenberg
-
yo,
Wenn es also überhaupt Sinn ergibt, solche speziellen Feldnamen zu nutzen (das sollte bei vernünftiger Normalisierung bzw. vernünftiger Generalisierung des Problems nicht auftreten), dann muss man damit leben, dass man unterschiedliche Versionen pflegen muss.
das daten-design in rdbms ist leider eine sehr statische angelegenheit, einmal festgelegt hat man hinten raus schwierigkeiten wieder etwas zu ändern. das kann aber im widerspruch zu dem entsprechenden umfeld stehen, dass man modellieren soll, weil es sehr dynamisch ist und sich ständig dinge ändern. sauberer wäre es sicherlich, diese änderungen im daten-design immer mit zu gehen, praktisch ist es aber ausgeschlossen, weil die entwicklung zu schnell geht.
da kann man sich dann schon noch anders behelfen, als ständig neue versionen zu pflegen. es ist aber ein abwiegen der vor und nachteile. ich habe mal eine solche situation gehabt für eine edv-inventarverwaltung. die hardware hat sicherlich unterschiedliche eigenschaften, ein Monitor braucht nicht die werte einer festplatte, etc. man baut sich eben das daten-design so, dass man neue hardware (in falle von kalle fahrrad und auto) in das bestehende layout hinzufügen kann inklusive seiner eigenschaften in eine zweite tabelle. musst halt schauen kalle, ob das ein möglicher weg für dich wäre.
Ilja
-
Moin!
ich habe mal eine solche situation gehabt für eine edv-inventarverwaltung. die hardware hat sicherlich unterschiedliche eigenschaften, ein Monitor braucht nicht die werte einer festplatte, etc.
Entweder man normalisiert sich die Konstruktion "Gerät kann beliebig viele Eigenschaften haben" im DB-Design heraus - dann hat man zur Abfrage des Geräts noch ein paar JOINs durchzuführen.
Oder man hat ein Sammelfeld "Sonstige Informationen", in denen alle diese Dinge in einem passenden Format drinstehen. Das kann vielleicht CSV sein, oder XML. Gerade XML wird von Datenbanken heutzutage durch integrierte XML-Funktionen bzw. XPath nutzbar gemacht. Dann darf man natürlich nicht mehr allzuviel Möglichkeiten oder Performance für das feine Suchen erwarten, aber oftmals sind solche Detaildaten nur der Vollständigkeit halber abgespeichert, dienen aber im Prinzip nur als Dekoration.
- Sven Rautenberg
-
Moin, Sven!
Entweder man normalisiert sich die Konstruktion "Gerät kann beliebig viele Eigenschaften haben" im DB-Design heraus - dann hat man zur Abfrage des Geräts noch ein paar JOINs durchzuführen.
Ich denke, du hast mein Problem gar nicht verstanden. Vielleicht, weil mein Beispiel nicht IT- gerecht war.
Eine neue Programmversion soll fehlende Tabellen- Felder tolerieren. Und du meinst, mit JOINS auf nicht vorhandene Tabellen (weil älterer DB- Stand) ist das zu beheben?
Ilja hat mich verstanden.
Oder man hat ein Sammelfeld "Sonstige Informationen", ... vielleicht CSV
Behalte ich mal im Hinterrkopf ...
Ich muss mich wohl davon lösen, beim Update *alle* Felder anzusprechen. Sondern nur die Felder, die von der Erfassungsmaske gesendet werden.
Bleibt die Frage, wie ich erkenne, dass ein Feld geleert werden soll. Also für jedes Feld *in der Erfassungsmaske* noch ein hidden- Hinweis: "Dieses Feld gilt".
Und dann hat der Fahrradhändler Maske A und der Autohändler Maske B bei gleichem Verarbeitungsprogramm. So könnte es gehen. Aber viel komplizierter als ich hoffte ...
Kalle
-
Hallo,
» Entweder man normalisiert sich die Konstruktion "Gerät kann beliebig viele Eigenschaften haben" im DB-Design heraus - dann hat man zur Abfrage des Geräts noch ein paar JOINs durchzuführen.
Ich denke, du hast mein Problem gar nicht verstanden. Vielleicht, weil mein Beispiel nicht IT- gerecht war.
doch sicher. Du hast vermutlich Sven nicht verstanden :-)
Nehmen wir wieder Dein (zugegeben konstruiertes) Auto-/Fahrradproblem:
Du hast mit Fahrrädern angefangen, deswegen hast Du jetzt die Tabelle "Ware":Bezeichnung | Sitz | Lenker | Gangschaltung | Licht vorn | Licht hinten
-----------------------------------------------------------------------------
Hollandrad | superweich | hoch | NULL | Standard | Standard
BMX-Bike | sichtbar | gerade | NULL | NULL | NULL
Rennrad | hart | tief | 27-Gang | NULL | NULLEine neue Programmversion soll fehlende Tabellen- Felder tolerieren. Und du meinst, mit JOINS auf nicht vorhandene Tabellen (weil älterer DB- Stand) ist das zu beheben?
Dein nächster Kunde verkauft Autos, Du benötigst zusätzliche Spalten:;
Bezeichnung | Sitz | Lenker | Gangschaltung | Licht vorn | Licht hinten | Schiebedach | Ersatzreifen | Kofferaumdeckel
------------------------------------------------------------------------------------------------------------------------
R4 | Camping | Rad | Knüppel | vorhanden | vorhanden | NULL | Notrad | StandardStatt dessen meint Sven, dass Du für die Eigenschaften eine eigene Tabelle "Eigenschaften" anlegen solltest:
id | Eigenschaft
----------------
1 | Sitz
2 | Lenker
3 | Gangschaltung
4 | Licht vorn
5 | Licht hintenund eine Zuordnungstabelle:
id_ware | id_eigenschaft | wert
-------------------------------------
1 | 1 | superweich
1 | 2 | hoch
1 | 4 | Standard
1 | 5 | StandardWelche Eigenschaften Deine Ware hat, bekommst Du nun über die von Sven angesprochenen JOINs heraus, neue Eigenschaften (wegen neuer Ware) benötigen keine neuen Spalten, sondern einfach neue Einträge in der Eigenschaftentabelle. Ein Nachteil bei dieser Geschichte ist, dass der Datentyp meiner Spalte "wert" alles Mögliche aufnehmen können muss, d.h. es wird ein Zeichenketten-Datentyp werden, während man bei eigenen Spalten den Datentyp auswählen kann, der am besten passt.
Ilja hat mich verstanden.
Ich gehe davon aus, dass Ilja mit
» » ein Monitor braucht nicht die werte einer festplatte, etc. man baut sich eben das daten-design so, dass man neue hardware (in falle von kalle fahrrad und auto) in das bestehende layout hinzufügen kann inklusive seiner eigenschaften in eine zweite tabelle. musst halt schauen kalle, ob das ein möglicher weg für dich wäre.
prinzipiell das gleiche gemeint hat.
Freundliche Grüße
Vinzenz
-
yo,
Ich gehe davon aus, dass Ilja ...
prinzipiell das gleiche gemeint hat.ja, wobei ich ja immer auch komisch ideen habe. ich würde zusätzlich noch zwei definitionts-tabellen anlegen, sprich welche objekte gibt es in einer tabelle und ihre eigenschaften in eine andere tabellen, die dann mit einem fremdschlüssel in einer 1:N beziehung miteinander verbunden sind. so weit kein problem. ich würde diese beiden tabellen aber nicht mit anderen tabellen referenzieren, wo dann die konkreten werte drinne stehen. muss aber jeder selbst wissen.
Ilja
-
-
-
-
-
-
-