Zum Thema GC: Schmarrn hoch 3
GC spart Zeit. Denn er kann den Speicher effizienter verwalten als es mit manueller Speicherfreigabe möglich wäre.
Dennoch ist Java wegen des Speichers langsamer. Dies liegt aber nicht am GC, sondern daran das einfach von Haus aus für kleinstObjekte mehr Speicher benötigt wird. Und Speicher sinnvoll zu beschreiben kostet nunmal Zeit.
Nur eben die Aufräumzeit selbst ist schneller als du es z.b. mit dem c++ free erreichen könntest. Ja ich weiß dies wirst du mir jetzt nicht glauben.
---
Zum Thema DB:
Kauf dir ein Buch zum Thema JDO. Ja ich weiß, die Teile kosten gleich mal 40 Euro ;o)
Argumentation für den Chef: Freiheit
Du kannst bei Bedarf einen höherwertigeren Mapper verwenden. Zu Beginn verwendest du jpox.org oder jcredo, die eine brauchbare freie Version anbieten. Im Falle eines Engpasses kannst du Caches dazustecken oder Produkte anderer Hersteller verwenden. Der Migrationsaufwand wird hierbei so gering wie möglich bleiben. Versuch gar nicht erst dir das ohne Fachliteratur beizubringen, denn du wirst dir damit keinen Gefallen tun.
Zum Thema Tabellenstruktur: Ja üblicherweise verwendet so ein Mapper exakt eine Tabelle pro Objekt. Selbst bei einer 1:1 Verbindung mapped man auf 2 Tabellen. Dennoch die daraus resultierenden Joins kosten üblicherweise Performance, wodurch manchmal hier denormalisiert wird.
JDO bietet dir zudem das Argument gegebenfalls später ohne Änderung des Codes auf eine ObjektDB umsteigen zu können. Du kannst aber auch einfach z.b. einige Namespaces aus der Maschine 1 beziehen, die restlichen Objekte wiederum von der Maschine 2. Derartige Änderungen beeinflußen nicht die Applikationslogik, wodurch sie später im lebenden System beim Auftreten des Engpasses relativ leicht vorzunehmen sind.
Ansonsten wenn du dich gegen JDO & Co entscheidest solltest du dir zumindestens das DAO Designpattern antun. Hierzu verweise ich zu http://java.sun.com/blueprints/patterns/DAO.html
Abschließend noch ein kleiner Link ins eigene Forum:
http://board.aenaeis.org/index.php?showtopic=220
Für meinen Zweck ergab sich JPox als geeignetste Implementierung. Bei dir würde ich vielleicht eher Richtung Jcredo schielen.
Alternativ zu JDO gäbe es noch den pragmatischen Weg => hibernate. Hierbei hast du aber das Problem das du kein Interface hast, das dir den Wechsel der Implementierung ermöglichen würde. Dafür ist das Tool an sich bereits reifer als die momentan vorhandenen JDO Implementierungen wie z.b. jpox. Dennoch strategisch gesehen halte ich hibernate für das falsche Pferd. JDO geht in Richtung lightwight Peristierung wärend Hibernate jetzt von JBoss aufgekauft wurde und somit bewußt Richtung EJB 3 getrieben wird.
cybi
GC spart Zeit. Denn er kann den Speicher effizienter verwalten als es mit manueller Speicherfreigabe möglich wäre.
Dennoch ist Java wegen des Speichers langsamer. Dies liegt aber nicht am GC, sondern daran das einfach von Haus aus für kleinstObjekte mehr Speicher benötigt wird. Und Speicher sinnvoll zu beschreiben kostet nunmal Zeit.
Nur eben die Aufräumzeit selbst ist schneller als du es z.b. mit dem c++ free erreichen könntest. Ja ich weiß dies wirst du mir jetzt nicht glauben.
---
Zum Thema DB:
Kauf dir ein Buch zum Thema JDO. Ja ich weiß, die Teile kosten gleich mal 40 Euro ;o)
Argumentation für den Chef: Freiheit
Du kannst bei Bedarf einen höherwertigeren Mapper verwenden. Zu Beginn verwendest du jpox.org oder jcredo, die eine brauchbare freie Version anbieten. Im Falle eines Engpasses kannst du Caches dazustecken oder Produkte anderer Hersteller verwenden. Der Migrationsaufwand wird hierbei so gering wie möglich bleiben. Versuch gar nicht erst dir das ohne Fachliteratur beizubringen, denn du wirst dir damit keinen Gefallen tun.
Zum Thema Tabellenstruktur: Ja üblicherweise verwendet so ein Mapper exakt eine Tabelle pro Objekt. Selbst bei einer 1:1 Verbindung mapped man auf 2 Tabellen. Dennoch die daraus resultierenden Joins kosten üblicherweise Performance, wodurch manchmal hier denormalisiert wird.
JDO bietet dir zudem das Argument gegebenfalls später ohne Änderung des Codes auf eine ObjektDB umsteigen zu können. Du kannst aber auch einfach z.b. einige Namespaces aus der Maschine 1 beziehen, die restlichen Objekte wiederum von der Maschine 2. Derartige Änderungen beeinflußen nicht die Applikationslogik, wodurch sie später im lebenden System beim Auftreten des Engpasses relativ leicht vorzunehmen sind.
Ansonsten wenn du dich gegen JDO & Co entscheidest solltest du dir zumindestens das DAO Designpattern antun. Hierzu verweise ich zu http://java.sun.com/blueprints/patterns/DAO.html
Abschließend noch ein kleiner Link ins eigene Forum:
http://board.aenaeis.org/index.php?showtopic=220
Für meinen Zweck ergab sich JPox als geeignetste Implementierung. Bei dir würde ich vielleicht eher Richtung Jcredo schielen.
Alternativ zu JDO gäbe es noch den pragmatischen Weg => hibernate. Hierbei hast du aber das Problem das du kein Interface hast, das dir den Wechsel der Implementierung ermöglichen würde. Dafür ist das Tool an sich bereits reifer als die momentan vorhandenen JDO Implementierungen wie z.b. jpox. Dennoch strategisch gesehen halte ich hibernate für das falsche Pferd. JDO geht in Richtung lightwight Peristierung wärend Hibernate jetzt von JBoss aufgekauft wurde und somit bewußt Richtung EJB 3 getrieben wird.
cybi
