oop

[Gargantua]

Wie siehts aus mit OOP?

[mifritscher]

wenn du ne gescheite oo-DB findest, die einen sql-Dialekt kann und nicht grad schnarchlahm ist

[Gargantua]

OOP-DB?
Oracle. Kann im Gegensatz zu MySQL ne ganze Ecke mehr SQL, kann OOP unso; solang man den nötigen RAM hat (400MB für Oracle allein) is die auch recht fix...
..nur Oracle installieren unso is ne ziemliche shicearbeit .
Man kann aber auch mit ner normalen, d.h. relationalen Datenbank OOP-Porgrammierte Daten speichern [jaja, anner FH machen wir größtenteils Java, und da kommt man um OOP kaum rum..].

[mifritscher]

auch wenns offtopic wird:
das Problem ist dass man dauernd Daten zwischen DB und php/java übersetzen muss. Ideal wäre eine DB, dessen Einbindung direkt Java-Objekte erzeugt und Änderungen sowohl per DB als über OOP in die DB speichert (ein UPDATE blah set test=(SELECT test from blah2 where blah.id=blah2.id) ist bissle schneller als wenn man das manuell über die Objekte macht...)
also bei select * from user where name like "test%" mir ein Array mit den Userobjekten erzeugt, wobei ich natürlich der DB sagen muss dass das Objekt User zur Tabelle User gehört.
Die meisten Appserver speichern die Objekte nur bis
zum nächsten Neustart, und "klassische" per sql drauf zugreifen kann man auch nicht, sodass man entweder manuell Indexe aufbauen muss oder es derbe lahm ist, und die Universalität von SQL hat man bei beiden nicht.

Und 400 MB ram ist bissle viel^^

Naja, wir müssen da bissle aufräumen, manches stammt noch aus der Anfangszeit, wo wir ziemlich viele Hacks gemacht hatten um ein Ergebniss zu bekommen...

[Gargantua]

Läuft den im Hintergrund die Programmlogik mit Java, oder meintest du das nur als Beispiel?
Wie auch immer genau - zur OOP gehören auch so Sachen wie die gute alter 3-Schichten-Architektur (oder 3 Tier), wahlweise auch türlich mit mehr/weniger Schichten.
Banal ausgedrückt, du baust dir ne zwischenschicht (in Java bzw. der Programmiersprache deiner Wahl) in der du die Prinzipiellen DB-Sachen ausprogrammiert hast - Verbindungsaufbau, abbau, datentransfer...
In jeder Klasse hast du dann halt die üblichen Methoden, also speichern, laden und solche Sachen, welche intern dan über die Verbindgsklasse auf die DB zugreifen..

kA wie weit du dich jetzt mit so Sachen auskennt, also verzeih wenn ich hier wieder Kram erwähn den du/ihr schon zig mal gehört & gemacht habt^^

btw:
Edith weißt mich darauf hin das sowas sicher nicht viele Leute interessiert ^^ also auch gerne per pm weiter

[mario]

Meiner Meinung nach ist btw nich komplex genug um es in p zu machen. Warum sich mit soviel Overhead rumschlagen wenn es auch pro Seite 1-2 ordentliche Querys machen

Ich weiss zwar nicht wie es bei btw aussieht, aber normal erreicht ein Browsergame keine Größe bei der oop einen Vorteil von wegen Wartbarkeit & Übersichtlichkeit bringen würde. Da kommts erstmal nur auf Laufzeit an

[Nomad]

alsoo... der code ist in der tat etwas Chaotisch, aber man kann sich mit etwas Mühe zurecht finden. :->
Ansonstne ist, nach dem was Fritscher mir so erzählt hat laufzeit bisher kein Problem, die CPU idelt größtenteils vor sich hin.

Und ja, ich bin nen Fan von oop

[Bilbo]

Bin auch nen Fan von OOP, aber ifrit ist da ziemlich Anti, da er mit den ganzen Datenbanksystemen irgendwie sich nciht anfreunden kann

[Gargantua]

Muss man auch nicht, geht ja auch mit ner normalen relationen DB (auch mit MySQL wunderbar machbar). Wobei das wirklich eckliger auszulesen ist

[mario]

Lohnt sich OOP bei php überhaupt?
ich seh da immer nur den ganzen Overhead an Daten die das Objekt zwar dann hat, aber die praktisch nie gebraucht werden, oder nur bei jeder 10ten Seite ..

In den Shared Memory kann man die Objekte ja glaube auch nicht legen (berichtigt mich wenn ich falsch liege), deswegen würde sich dass doch eher für Java als für php lohnen. Da bleiben die Objekte ja die ganze Session über erhalten und werden nich bei jedem Aufruf neu gebildet.

[mifritscher]

wobei bei Java halt wieder das Problem ist dass die meisten Appserver es nicht dauerhaft abspeichern, spätestens nach nem Reset sind die Daten weg, weswegen man die Daten "händisch" sichern muss. Entweder bei jeder schreibenden Aktion, wo man dann unterm Strich kaum was gewinnt, oder alle 5 Minuten oder so, wobei man da halt immer Gefahr läuft Daten zu verlieren, außerdem hat man dann alle 5 Min die geballte Ladung.

Zudem ich dann die nützlichen Sachen von SQL wie Indexe, Joins über alles mögliche etc. umständlich nachbilden müsste

Wenn es eine oop-DB gibt, die man ohne Fummelei direkt so an Java andocken könnte dass es keinen Unterschied macht ob man direkt Java-Objekte oder DB-Objekte (die entsprechenden Klassen müssen natürlich definiert sein, z.B. bissle vereinfacht pro Tabelle eine Klasse) anspricht und man dennoch SQL mit seinen Vorteilen verwenden kann bin ich sofort dabei.
Grottenlahm oder instabil sollte sie natürlich auch nicht sein

[Gargantua]

Ich verweise wieder auf Oracle, damit geht das glaub ich ganz gut . Die Tabellen zu erstellen is türlich bissl komplizierter (immerhin sinds keine Strings mehr, sondern Objekte) - dafür kann man die Dinger einfacher Speichern/Lesen.

@mario: Ich bin eigentlich davon ausgegangen das BR und noch so paar Kleinigkeiten kein Php sind (irgendwie sowas wurd da mal angedeutet..?). Wenn eh Cronjobs o.ä. aufm Server vorhanden sind ists ja kein Problem die Daten da einmal (mit c++, Java oder was auch immer) pro Stunde objektorientiert auszulesen, um den BR zu berechnen.
Das man für die Anzeige der Roids so nen Aufwand nicht betreiben muss sollte auch klar sein .

[Nomad]

Die Brs sind wunderschönes PHP - insbesondere seit ich die Datei für meine "Inovationen" komplett durch den Wolf gedreht habe ;D