Ich musste mal eine Wawi an Oxid anbinden. Das war die Hölle: Ich weiß nicht mehr viel, aber an zwei Dinge erinnere ich mich: * keine ordentliche/aktuelle Dokumentation der Datenbank (Stand 2007) * sowas von unnormalisierte Datenbanken (Auftragspositionen mit, wieviel waren es noch gleich, ..., 40+ Feldern?? (wenn es nicht an der Stelle war, war es woanders))
Kombiniere die zwei Punkte, und fertig ist der Überstundenapparat :)
Alles in allem ist das einzig "Gute" der default-mäßige "moderne" Look von Oxid, garniert mit viel CSS.
Ich hab ne Tabelle geschrieben die hatte mal 58 Felder. Und es war gut so, den Normalisierung ist nicht immer das wichtigste. Je nach Situation und Anforderungen kann ein nicht-normalisiertes Design sowohl praktischer in der Handhabung, wie auch schneller sein. Jedoch kann es natürlich auch exakt anders herum sein.
Viele Felder sind nicht automatisch böse. Kommt drauf an was gemacht wurde. (ich kenne die beschriebene Tabelle nicht)
Nein, über Normalisierung möchte ich nicht streiten.
Aber glaub mir, in diesem Fall war es nicht angebracht, das war Die Totale Über Redundanz. Und man sollte NIE direkt in eine Oxid-Datenbank eingreifen, egal wie sehr ich es versucht habe, das Hinzufügen einzelner Datensätze hat i.d.R. die DB korrumpiert.
Also: API nutzen! Aber: Das Linux-Magazin hat nichts gutes zu berichten bez. Entwicklung: http://www.linux-magazin.de/news/e_shop_4_0_von_oxid_konvertiert_zur_gpl
P.S. auto_increment war den Entwicklern damals auch fremd, und nicht wenige Queries waren waren dreifach und mehr verschachtelt, trotz Un-Normalisierung.
* keine ordentliche/aktuelle Dokumentation der Datenbank (Stand 2007)
* sowas von unnormalisierte Datenbanken (Auftragspositionen mit, wieviel waren es noch gleich, ..., 40+ Feldern?? (wenn es nicht an der Stelle war, war es woanders))
Kombiniere die zwei Punkte, und fertig ist der Überstundenapparat :)
Alles in allem ist das einzig "Gute" der default-mäßige "moderne" Look von Oxid, garniert mit viel CSS.
Jedoch kann es natürlich auch exakt anders herum sein.
Viele Felder sind nicht automatisch böse. Kommt drauf an was gemacht wurde. (ich kenne die beschriebene Tabelle nicht)
Aber glaub mir, in diesem Fall war es nicht angebracht, das war Die Totale Über Redundanz. Und man sollte NIE direkt in eine Oxid-Datenbank eingreifen, egal wie sehr ich es versucht habe, das Hinzufügen einzelner Datensätze hat i.d.R. die DB korrumpiert.
Also: API nutzen! Aber: Das Linux-Magazin hat nichts gutes zu berichten bez. Entwicklung: http://www.linux-magazin.de/news/e_shop_4_0_von_oxid_konvertiert_zur_gpl
P.S. auto_increment war den Entwicklern damals auch fremd, und nicht wenige Queries waren waren dreifach und mehr verschachtelt, trotz Un-Normalisierung.