text.skipToContent text.skipToNavigation
background-image

Java-Persistenz mit Hibernate von Bauer, Christian (eBook)

  • Verlag: Hanser Fachbuchverlag
eBook (PDF)
47,99 €
inkl. gesetzl. MwSt.
Sofort per Download lieferbar

Online verfügbar

Java-Persistenz mit Hibernate

Hibernate (engl. für Winterschlaf halten) ist momentan das populärste Java-Persistenz-Tool.

Das Open-Source-Framework ermöglicht es, den Zustand eines Objekts rechnerunabhängig in einer relationalen Datenbank speichern und daraus Datensätzen wiederum Objekte zu erzeugen. Wer mit Hibernate arbeitet braucht bis zu 30% weniger Anwendungscode und steigert so Produktivität und Performance. In dieser Neuauflage des Bestsellers Hibernate in Action decken Christian Bauer und Gavin King, der Gründer des Hibernate-Projekts, Hibernate 3.2 detailliert ab. Sie bieten dreifachen Nutzen: Ein Tutorial für Hibernate, Java Persistenz und EJB 3.0 für Einsteiger. Unterstützung beim Erlernen aller grundlegenden und fortgeschrittenen Features von Hibernate. Eine Referenz für alle, die eine vollständige und technisch genaue Definition der Hibernate-Funktionalitäten benötigen. Der Leser profitiert von den Best Practices für das Datenbank-Design, das Object/Relational-Mapping und die Techniken für die Performanceoptimierung. Das Buch wird abgerundet durch ein Kapitel zu JBoss Seam, dem neuen Web Application Framework für Java EE, das auf EJB 3.0, JSF und Hibernate aufbaut. Im Internet: Der Sourcecode der Beispiele aus dem Buch.

Ein Buch für alle Java-Programmierer!

Produktinformationen

    Format: PDF
    Kopierschutz: watermark
    Seitenzahl: 729
    Sprache: Deutsch
    ISBN: 9783446413825
    Verlag: Hanser Fachbuchverlag
    Größe: 6778 kBytes
Weiterlesen weniger lesen

Java-Persistenz mit Hibernate

8 Legacy-Datenbanken und eigenes SQL (S. 285-286)

Die Themen dieses Kapitels:

Integration von Legacy-Datenbanken und knifflige Mappings
Anpassung von SQL-Anweisungen
Verbesserung des SQL-Schemas mit eigener DDL

Bei vielen Beispielen in diesem Kapitel geht es um "schwierige" Mappings. Das erste Mal wenn Sie Probleme mit dem Erstellen eines Mappings bekommen, wird wahrscheinlich sein, wenn das Datenbankschema eines Legacy-, also eines Altsystems nicht verändert werden kann. Wir besprechen typische Probleme, auf die Sie bei einem solchen Szenario stoßen werden, und wie Sie Ihre Mapping-Metadaten anpassen können, statt Ihre Applikation oder das Datenbankschema zu verändern.

Wir zeigen Ihnen auch, wie Sie das von Hibernate automatisch generierte SQL überschreiben können. Dazu gehören SQL-Abfragen, DML-Operationen (Create, Update, Delete) und auch die automatische DDL-Generierung von Hibernate. Sie erfahren, wie Stored Procedures und benutzerdefinierte SQL-Funktionen gemappt werden und wie Sie die richtigen Integritätsregeln in Ihrem Datenbankschema anwenden. Dieser Abschnitt wird besonders dann nützlich sein, wenn Ihr Datenbankadministrator die vollständige Kontrolle braucht (oder wenn Sie selbst der DBA sind und Hibernate auf SQL-Ebene optimieren wollen). Wie Sie sehen, sind die Themen dieses Kapitels breit gestreut, Sie brauchen nicht alles am Stück zu lesen. Sie können einen Großteil dieses Kapitels als Referenzmaterial betrachten und darauf zurückgreifen, wenn ein bestimmtes Problem auftritt.

8.1 Integration von Datenbanken aus Altsystemen

In diesem Abschnitt decken wir hoffentlich alle die Eventualitäten ab, auf die Sie bei der Arbeit mit einer vorhandenen Altsystem-Datenbank oder (und das ist oft das Gleiche) einem eigenartigen bzw. kaputten Schema arbeiten müssen. Wenn Ihr Entwicklungsprozess Top-down ist, können Sie diesen Abschnitt jedoch überspringen. Darüber hinaus empfehlen wir Ihnen, dass Sie zuerst alle Kapitel über Klassen-, Collection- und Assoziations- Mappings lesen, bevor Sie versuchen, mit Reverse Engineering ein komplexes Legacy- Schema anzugehen.

Wir müssen Sie warnen: Wenn Ihre Applikation ein vorhandenes Legacy-Datenbankschema erbt, sollten Sie an diesem Schema normalerweise so wenig Änderungen wie möglich vornehmen. Jede Änderung daran könnte andere vorhandene Applikationen beeinträchtigen, die auf die Datenbank zugreifen. Möglicherweise müssen Sie auch eine kostspielige Migration vorhandener Daten in Betracht ziehen. Im Allgemeinen ist es nicht möglich, eine neue Applikation zu erstellen und keine Änderungen am vorhandenen Datenmodell zu machen - eine neue Applikation bedeutet normalerweise zusätzliche Business-Anforderungen, die naturgemäß eine Weiterentwicklung des Datenbankschemas nach sich zieht. Wir werden von daher zwei Arten von Problemen betrachten: solche, die mit den sich verändernden Business-Anforderungen zu tun haben (die im Allgemeinen nicht ohne Überarbeitung des Schemas gelöst werden können), und solche, die sich nur darauf beziehen, wie Sie das gleiche Business-Problem in Ihrer neuen Applikation repräsentieren wollen (gewöhnlich kann das ohne Änderungen am Datenbankschema gelöst werden, aber nicht immer).

Es sollte klar sein, dass die erste Art von Problemen schon erkennbar wird, wenn man sich nur das logische Datenmodell anschaut. Die zweite bezieht sich häufiger auf die Implementierung des logischen Datenmodells als physisches Datenbankschema. Wenn Sie diesen Beobachtung zustimmen, merken Sie, dass Schemaveränderungen bei folgenden Problemen erforderlich sind: Einfügen neuer Entities, Refakturierung vorhandener Entities, Einfügen neuer Attribute bei vorhandenen Entities und Überarbeitungen der Assoziationen zwischen Entities. Bei den ohne Schemaveränderungen lösbaren Problemen geht es gewöhnlich um unpraktische Tabellen- oder Spaltendefinitionen

Weiterlesen weniger lesen

Kundenbewertungen