Verschiedene Persistenz Strategien

[Dandro]

Hallo nochmal

Ich möchte erstmal anmerken, dass ich mir mit der Wahl des Forums nicht wirklich sicher war, also entschuldigt, wenn ich das falsche Forum gewählt haben sollte.

Ich versuche im Moment eine Persistenz Engine für eines meiner Projekte zu konzipieren. Die Anforderungen wären, dass die Persistenz über verschiedene Layer möglich sein soll. Dass heißt es soll beispielweise die Möglichkeit einer
MySQL Datenbankanbindung geben, allerdings auch, sofern gewünscht, eine einfache Sicherung in Dateien. Mehr bräuchte ich für den Anfang auch nicht, später würde evtl. ein XML Layer dazukommen, aber das ist jetzt nicht so wichtig.

Die Datenbank Anbindung würde ich mit Hibernate realisieren, weil es zum Schluss doch verschiedene und komplexe Objekte werden, also strebe ich eine Umsetzung mit Objektrelationalem Mapping an. Falls es vielleicht dafür eine bessere Lösung gibt, immer her damit

Die Umsetzung der File-Variante bereitet mir allerdings Probleme. Das Programm wird letztlich eine große Datenbasis zur Verfügung haben, weshalb es wenig performant sein wird ALLE Datenfiles einzulesen und als Objekte im RAM zu lassen, oder irre ich mich da? Eine andere Möglichkeit sehe ich allerdings im Moment nicht um beispielweise ein bestimmtes Objekt zu laden. Mir kam da eine Art "Map" in den Sinn, die die Objekte und deren Position in einer File beschreibt. Allerdings wären die Möglichkeiten damit sehr beschränkt. Und ich könnte ein Objekt nur nach einem Kriterium heraussuchen (oder auch zwei, je nachdem wieviele Sinn machen). Nicht aber so wie bei SQL "Select * FROM table WHERE [....]", was ich letztendlich aber auch gerne für das Filesystem erreichen wollen würde.

Gibt es schon gute Strategien in der Kategorie oder ein Konzept der Umsetzung eines solchen Systems?

PS.: Ich hoffe es wurde klar, wo mein Problem liegt XD

 

[foobar]

Warum willst du überhaupt Files als Persistenzlayer verwenden? DB + Hibernate ist doch völlig OK. Wenn du dann noch den DB-Code mit Hilfe des DAO-Patterns kappselst, biste auf der sicheren Seite.

 

[Guest]

Hier ein Vorschlag für die Struktur der DAO-Schicht.

public interface GenericDAOIF<T>
{
   List<T> readAll() throws DAOException;
   T create(T dao) throws DAOException;
   T read(Long id) throws DAOException;
   T update(T dao) throws DAOException;
   void delete(T dao) throws DAOException;
}

public interface PersonDAOIF extends GenericDAOIF<Person>
{
   ... spezielle DAO Methoden zum Lesen von Person
}

class JPAPersonDAO implements PersonDAOIF
{
   ... DAO Implementierung mit JPA bzw. Hibernate
}

class JDBCPersonDAO implements PersonDAOIF
{
   ... DAO Implementierung mit JDBC
}

class FilePersonDAO implements PersonDAOIF
{
   ... DAO Implementierung mit Dateien
}

public class PersonDAOFactory
{
   private PersonDAOFactory() {}

   public static PersonDAOIF createPersonDAO() throws DAOException
   {
      switch(Configuration.getDAOImplementation())
      {
         case DAOImplementation.JPA:
            return new JPAPersonDAO();
         case DAOImplementation.JDBC:
            return new JDBCPersonDAO();
         case DAOImplementation.FILE:
            return new FilePersonDAO();
         default:
            throw new DAOException(String.format("Unsupported DAO Implementation: %s", Configuration.getDAOImplementation()));
      }
   }
}

 

[kleiner_held]

Ich wuerde auch eine reine Datenbank+Hibernate Lösung empfehlen. Für Installationen bei denen keine externe DB gewünscht ist, kannst du dann eine HSQL-DB einfach mit in dein Programm einbauen, die würde dann beim Programmstart implizit mit gestartet und die Daten werden im Endeffekt auch nur in Dateien gespeichert.

 

[deleted]

Also "SELECT" im Dateisystem.
Microsoft hat es versucht. Microsoft ist kläglich gescheitert

Ansonsten klar:
Du kannst z.B. HashMaps nutzen, die auf Dateien verweisen.
z.B. hast du einen Vektor, welcher alle bereits geladenen Objekte hat.
Auf alle ungeladenen zeigen HashMaps.

wenn du dann deinem eigenen SQL Objekt den String
"SELECT KUNDENOBJEKT FROM KUNDE WHERE NAME = X" übergibst, musst du den nur:
- mit einem Automaten auf Syntaxkorrektheit prüfen
- mit StringTokenizer zerlegen
- deine gewünschten Operationen ausführen.

z.B. verweist dann die HashMap "KundenNamen" mit jeweils dem Namen auf ein Fileobjekt, in dem das serialisierte Kundenobjekt liegt.

Ist dieses noch nicht im Vektor, wird es in den RAM geladen.

Mein persönlicher Kommentar zu sowas:
Ich hoffe du hast nen AKW neben der Haustür...

Die sinnvollste Lösung ist, du nimmst eine ordentliche Datenbank

 

[AlArenal]

Also "SELECT" im Dateisystem.
Microsoft hat es versucht. Microsoft ist kläglich gescheitert

Sind sie nicht. Nur weil es in Vista nicht drin ist, ist das Thema als solches noch lange nicht durch. Rausgenommen wurde es nur aus Performance-Gründen. Zu dumm nur für MS, dass Oracle auch für MS zu groß ist, um sie aufzukaufen (iFS).

Die sinnvollste Lösung ist, du nimmst eine ordentliche Datenbank

Der Frager wollte wohl auch kaum eine "unordentliche" benutzen...

 

[deleted]

Also "SELECT" im Dateisystem.
Microsoft hat es versucht. Microsoft ist kläglich gescheitert

Sind sie nicht. Nur weil es in Vista nicht drin ist, ist das Thema als solches noch lange nicht durch. Rausgenommen wurde es nur aus Performance-Gründen. Zu dumm nur für MS, dass Oracle auch für MS zu groß ist, um sie aufzukaufen (iFS).

Die sinnvollste Lösung ist, du nimmst eine ordentliche Datenbank

Der Frager wollte wohl auch kaum eine "unordentliche" benutzen...

Nun wenn ich etwas versuche und lauthals ankündige, aber nicht hinbekomme, und wie du sagst, den Kokurrenten, der es könnte, nicht aufkaufen kann...
Wo bin ich denn dann NICHT gescheitert?

Und ich glaub, du hast ganz genau verstanden, was ich mit "ordentliche Datenbank" gemeint hab.
Nämlich eine Datenbank eines etablierten Herstellers :wink:

 

[AlArenal]

Geschietert ist man erst dann, wenn man gar nicht hinbekommt. Aufgeschoben ist nicht aufgehoben.

Und "etablierter Hersteller" ist oft nur eine nette Umschreibung für eine Liste von Namen, die man in Unkenntnis von Alternativen via Suchmaschine ratztfatz beisammen bekommt. Es ist aber nciht zwingend, dass ein jeder bei MySQL AB, Microsoft, Oracle, IBM, ... glücklich wird.
Sich u.U. selbst was zu stricken ist gar nicht soo ungewöhnlich.

One size doesn't fit it all.