-Peace- Geschrieben 4. Juni 2008 Geschrieben 4. Juni 2008 (bearbeitet) Hi @all, IST-Zustand Ich habe eine JSF Anwendung die auf einem Tomcat 6.0 läuft. Über Hibernate werden dabei Objekte aus der Datenbank geladen und wieder hineingeschrieben. Die Connection baue ich über die HibernateSessionFactory in einer ManagedBean mit Application Scope auf. Als DBMS verwende ich PostgreSQL 8.x. Das klappt alles recht gut.. ich habe folgendes Problem: Nun wollte ich gewisse Dokumente (meist .doc oder .ppt) als Attribute einer Tabelle hinzufügen. Zum Beispiel: Es gibt die Tabelle Prozesse und zu jedem Prozess git es ein Dokument. Ich würde dies dann mit einer ganz neuen Tabelle mit einer 1:1-Beziehung realisieren. Ich hab gelesen dass dafür die sogenannten BLOBs zum Einsatz kommen und dass man die Dateien direkt in die DB speichern kann oder einen Link auf die Datei speichern kann der auf die Datei auf der Festplatte verweißt. Allerdings kann man im 2ten Fall die Datei nicht wirklich löschen sondern nur den Link ... Ich habe keinen Schimmer wie ich mit den BLOBs arbeiten soll weder mit normalem JDBC noch mit Hibernate... Außerdem weiß ich auch nicht wie ich die Daten dann mit JSF 1.2 dann in die Datenbank über Hibernate hochladen soll, da es für JSF 1.2 keine Standard-Upload Komponente gibt und ich eigentlich keine anderen Komponenten von z.B. MyFace verwenden will. (Kann man das mit nem Servlet in JSF einbinden???) Ist es überhaupt möglich mit .doc Dateien so zu arbeiten, dass der Benutzer sie über einen Upload in die DB speichert und über z.B. einen Klick auf einen ActionLink sie öffnen kann??? Oder gar das es unterschiedliche Dateien sein können??? Im Grunde muss der Benutzer die Datei aus der Datenbank laden, öffnen, verändern und dann wieder in die Datenbank speichern können. Ist dies mit JSF 1.2, Hibernate überhaupt möglich und wie steht es mit der Performance? Ich weiß... Hört sich recht kompliziert an, doch ich bin für alle Tipps und Antworten dankbar, Grüße @all Bearbeitet 4. Juni 2008 von -Peace- Zitieren
perdian Geschrieben 4. Juni 2008 Geschrieben 4. Juni 2008 Nun wollte ich gewisse Dokumente (meist .doc oder .ppt) als Attribute einer Tabelle hinzufügen. [...] Ich würde dies dann mit einer ganz neuen Tabelle mit einer 1:1-Beziehung realisieren. [...] dass man die Dateien direkt in die DB speichern kann oder einen Link auf die Datei speichern kann der auf die Datei auf der Festplatte verweißt. Allerdings kann man im 2ten Fall die Datei nicht wirklich löschen sondern nur den Link ...Das ist alles eine Frage der Applikationslogik. Generell halte ich es für eine schlechte Idee große binäre Datenmengen in eine Datenbank zu schreiben - dafür ist eine relationale Datenbank nicht wirklich ausgelegt. Ich weiss nicht um welche Größenordnung wir hier reden aber bei sehr vielen und/oder sehr großen binären Daten leidet sehr schnell die Performance und die Antwortzeiten der Datenbank gehen telweise drastisch in den Keller. Die bessere Lösung hier ist tatsächlich sich nur den Pfad der Datei in der Datenbank zu speichern und die eigentliche Datei auf dem Filesystem liegen zu haben - genau dafür ist es ja da. Die Herausforderung "Datei löschen, wenn Datensatz gelöscht wird" lässt sich über verschiedene Wege implementieren. Ganz LowLevel kann ich einen Interceptor in Kombination mit Hibernate verwenden um über die entsprechenden Events informiert zu werden und beim Löschen aus der Datenbank ein Löschen auf dem Filesystem zu triggern. Schöner ist es allerdings auch hier direkt innerhalb der Applikation das entsprechend abzufangen und bevor das Löschen an die Persistenzschicht übergeben wird bereits die Datei vom Filesystem zu entfernen. Ich habe keinen Schimmer wie ich mit den BLOBs arbeiten soll weder mit normalem JDBC noch mit Hibernate... Zumindest bei Hibernate brauchst du das auch gar nicht. BLOBs sind ein Konzept der unterliegenden Datenbank, bei der Verwendung von Hibernate konzentrierst du dich aber auf die Applikationslogik und bekommst von der Art und Weise, wie die Datenbank die Objekte speicherst ja nichts mit. Konkret bedeutet das: Du musst überhaupt nichts machen! Bei einer Klassendefinition wie: @Entity @Table(name="foo"); public class X { public byte[] getSerializableObject() { } public void setSerializableObject(byte[] o) { } } merkt Hibernate automatisch, dass der entsprechende Typ nicht mit "Bordmitteln" in die Datenbank übertragen werden kann (es also keinen passenden Datenbanktyp gibt) und wird damit automatisch das entsprechende Objekt (in diesem Falle ein Byte-Array) serialisieren. Außerdem weiß ich auch nicht wie ich die Daten dann mit JSF 1.2 dann in die Datenbank über Hibernate hochladen soll, da es für JSF 1.2 keine Standard-Upload Komponente gibtAndere Baustelle, ich würde dafür einen eigenen Thread aufmachen oder noch besser: Google! Upload ist so ein häufig nachgefragtes Thema, da wirst du garantiert fündig werden. Ist es überhaupt möglich mit .doc Dateien so zu arbeiten, dass der Benutzer sie über einen Upload in die DB speichert und über z.B. einen Klick auf einen ActionLink sie öffnen kann?Ja, ist es. Ist dies mit JSF 1.2, Hibernate überhaupt möglich und wie steht es mit der Performance?Ja, es ist möglich - auch performant. Zitieren
-Peace- Geschrieben 4. Juni 2008 Autor Geschrieben 4. Juni 2008 schonmal vielen Dank für den input! Zitieren
Empfohlene Beiträge
Dein Kommentar
Du kannst jetzt schreiben und Dich später registrieren. Wenn Du ein Konto hast, melde Dich jetzt an, um unter Deinem Benutzernamen zu schreiben.