DeletedUser27242
Der Teil zum Thema Datenbanken ist völliger Mist, zwar sind einige Basics richtig drin, aber wir sind in 2016 Objektrelational hat ausgedient, entweder ich belasse es bei meiner klassischen relationalen Datenbank oder ich benutze gleich eine NoSQL-Datenbank, das No heißt weder Number noch "kein", sondern Not Only SQL. Diese Datenbanken verwalten große Datenmengen erheblich schneller, als konventionelle SQL-Datenbanken.
Set-Teile als Obergruppe zu nehmen macht theoretisch als auch praktisch nur wenig Sinn, da diese eigentlich extrahiert in einer n:m-Beziehung sind. Woher sollte man sonst bei einem Set-Item wissen ob das jetzt die Hose oder das Gewehr ist?
Für was auch immer du eine Sortiernummer brauchst ist mir ein Rätsel. Da Lege ich doch eine Sequence an(wenn wir bei relational bleiben). Z. B. SEQ_Boots. Die dann für jede Kategorie um 10000 erhöht, früher einfach um 10, aber das ist jetzt mal das kleinere.
Dann vergisst du, die Kategorie auszulesen, damit die Zuordnung zu einer Kategorie geschehen kann, sonst wird's lustig, denn du hättest im Inventar alles vorne. Der WHERE-Teil ist deutlich zu klein geraten.
Meine Empfehlung für Inno ist, den Zeitgeist mitzugehen und auf NoSQL umzusteigen, was sich im Web-Bereich als erheblich schneller erwiesen hat.
Denn die Daten kann man sich als JSON-Objekt holen, wodurch relativ schnell ein Objekt in der Programmiersprache gefüllt werden kann, besonders in einer Sprache wie PHP.
So wer das kauderwelsch jetzt nicht verstanden hat hier nochmal runter gebrochen:
Die Welt als Tabellen zu erfassen ist sinnfrei
Ein Stuhl ist ein Objekt, ein Auto ist ein Objekt, mit entsprechenden Werten, warum soll ich das ganze in eine Tabelle aufbrechen, wenn ich die Relevanten Daten dazu auch einfach als Objekt Stuhl mit den Attributen: (Höhe, Gewicht, Material, ...) als Objekt speichern kann und nur noch eine Abfrage zum auslesen brauche, anstelle von einer großen SQL-Abfrage, wo ich die Objekte dann Zeile für Zeile fülle.
By the way: Probleme kann es hier geben, wenn ich Infos aus der DB will, hab das ganze schön nach der 3. NF gestaltet. Nehmen wir jetzt mal einen PC als Beispiel, mich als Admin interessiert jetzt nicht nur, wie viel Arbeitsspeicher der hat, sondern auch auf welche Riegel das verteilt ist.
Jetzt muss ich zur Anzeige das Geräts eine Abfrage schreiben und dann für die Details zum Arbeitsspeicher noch eine Abfrage, damit ich über jeden einzelnen Riegel weis, was der für Daten hat.
Will ich dieses Problem mit einer einzelnen Abfrage lösen, erhalte ich vielleicht 2 oder 3 Datensätze zu einem PC, in denen sich jetzt nur die Details zum Arbeitsspeicher geändert haben.
Bei einer NoSQL-Datenbank, wo ich genau einen PC auslesen will, würde ich hier ein JSON-Objekt erhalten in dem ich die Daten ähnlich wie in einem Array bekomme:
{'Riegel 1'}->
.......{'Name'} -> Kingston DDR3 hxiel
.......{'Taktfrequenz in MHz'} -> 1600
.......{'Speicher in MB'} -> 4096
{'Riegel 2'}->
.......{'Name'} -> G.SKILL DDR3 qwerl
.......{'Taktfrequenz in MHz'} -> 1333
.......{'Speicher in MB'} -> 2048
Das Problem an der Sache ist, die NoSQL-Datenbanken sind ein klein wenig komplizierter, bedürfen dafür aber keinen Konstruktormethoden um Objekte auszuwerfen.
Sorry ich bin wieder ein wenig ausgeschweift, worum es prinzipiell geht:
Objektorientierte Programmierung mit einem relationalen Modell zu verbinden ist schlicht weg idiotisch. Ich sag ja auch nicht, ich muss jetzt erstmal 3 Tabellen anlegen, damit ich den Schrank erfassen kann, sondern mache das als Objekt, in dem ich einfach bekannte Einheiten wieder Nutze, wie z.B. Gewicht und Größe.
Set-Teile als Obergruppe zu nehmen macht theoretisch als auch praktisch nur wenig Sinn, da diese eigentlich extrahiert in einer n:m-Beziehung sind. Woher sollte man sonst bei einem Set-Item wissen ob das jetzt die Hose oder das Gewehr ist?
Für was auch immer du eine Sortiernummer brauchst ist mir ein Rätsel. Da Lege ich doch eine Sequence an(wenn wir bei relational bleiben). Z. B. SEQ_Boots. Die dann für jede Kategorie um 10000 erhöht, früher einfach um 10, aber das ist jetzt mal das kleinere.
Dann vergisst du, die Kategorie auszulesen, damit die Zuordnung zu einer Kategorie geschehen kann, sonst wird's lustig, denn du hättest im Inventar alles vorne. Der WHERE-Teil ist deutlich zu klein geraten.
Meine Empfehlung für Inno ist, den Zeitgeist mitzugehen und auf NoSQL umzusteigen, was sich im Web-Bereich als erheblich schneller erwiesen hat.
Denn die Daten kann man sich als JSON-Objekt holen, wodurch relativ schnell ein Objekt in der Programmiersprache gefüllt werden kann, besonders in einer Sprache wie PHP.
So wer das kauderwelsch jetzt nicht verstanden hat hier nochmal runter gebrochen:
Die Welt als Tabellen zu erfassen ist sinnfrei
Ein Stuhl ist ein Objekt, ein Auto ist ein Objekt, mit entsprechenden Werten, warum soll ich das ganze in eine Tabelle aufbrechen, wenn ich die Relevanten Daten dazu auch einfach als Objekt Stuhl mit den Attributen: (Höhe, Gewicht, Material, ...) als Objekt speichern kann und nur noch eine Abfrage zum auslesen brauche, anstelle von einer großen SQL-Abfrage, wo ich die Objekte dann Zeile für Zeile fülle.
By the way: Probleme kann es hier geben, wenn ich Infos aus der DB will, hab das ganze schön nach der 3. NF gestaltet. Nehmen wir jetzt mal einen PC als Beispiel, mich als Admin interessiert jetzt nicht nur, wie viel Arbeitsspeicher der hat, sondern auch auf welche Riegel das verteilt ist.
Jetzt muss ich zur Anzeige das Geräts eine Abfrage schreiben und dann für die Details zum Arbeitsspeicher noch eine Abfrage, damit ich über jeden einzelnen Riegel weis, was der für Daten hat.
Will ich dieses Problem mit einer einzelnen Abfrage lösen, erhalte ich vielleicht 2 oder 3 Datensätze zu einem PC, in denen sich jetzt nur die Details zum Arbeitsspeicher geändert haben.
Bei einer NoSQL-Datenbank, wo ich genau einen PC auslesen will, würde ich hier ein JSON-Objekt erhalten in dem ich die Daten ähnlich wie in einem Array bekomme:
{'Riegel 1'}->
.......{'Name'} -> Kingston DDR3 hxiel
.......{'Taktfrequenz in MHz'} -> 1600
.......{'Speicher in MB'} -> 4096
{'Riegel 2'}->
.......{'Name'} -> G.SKILL DDR3 qwerl
.......{'Taktfrequenz in MHz'} -> 1333
.......{'Speicher in MB'} -> 2048
Das Problem an der Sache ist, die NoSQL-Datenbanken sind ein klein wenig komplizierter, bedürfen dafür aber keinen Konstruktormethoden um Objekte auszuwerfen.
Sorry ich bin wieder ein wenig ausgeschweift, worum es prinzipiell geht:
Objektorientierte Programmierung mit einem relationalen Modell zu verbinden ist schlicht weg idiotisch. Ich sag ja auch nicht, ich muss jetzt erstmal 3 Tabellen anlegen, damit ich den Schrank erfassen kann, sondern mache das als Objekt, in dem ich einfach bekannte Einheiten wieder Nutze, wie z.B. Gewicht und Größe.
nur vom Mythos war ich etwas enttäuscht