@Herr K.
Danke für die ausführliche Antwort.
Für das Anlegen der Datenbankstruktur durch die Anwendung spricht, wie Du schon sagtest, eine gewisse Einfachheit. Die Pflege reduziert sich auf die Persistenzklassen und die enthaltenen Annotationen. Ein weiterer Vorteil ist sicherlich auch, dass Du keine Rücksicht auf den SQL Dialekt nehmen musst (z.B. ob man den Datentypen Datetime für Transact SQL oder Timestamp für SQLPlus benötigt).
Das ist genau der Grund warum ich die Tabellen gerne automatisch anlegen lassen möchte.
Den umgekehrten Weg möchte ich möglichst vermeiden (was bisher eigentlich recht gut klappt).
Was Du auch bedenken musst ist, dass Du getrennte Kompetenzen hast. Viele Firmen haben einen Datenbankadministrator, der nichts mit dem Systemadministrator zu tun hat, der die Applikation deployed. Hier kann es sein, dass der DB Admin gerne die Skripte zu einem beliebigen Zeitpunkt einspielen möchte und nur bestimmte Rechte auf dem zugehörigen Schema erteilt.
Da hast du natürlich recht. Aber nicht jeder Anwendung die eine Datenbank benötigt, setzt auf eine existierende DB Installation auf. Hier kommt es doch sehr auf den Anwendungsfall an. Es gibt ja durchaus dedizierte Maschinen/Serverkisten, die nur eine einzige Aufgabe erledigen, und damit auch nur einen einzige /große) Serveranwendung laufen haben. Oftmals werden die auch als "Blackbox" verkauft: Auspacken, anschließen, läuft. Oder: CD in Servermaschine einlegen, System installieren lassen, läuft. Einen extra DB Admin gibt es da nicht.
Aber gut, es gibt natürlich auch jede Menge Szenarien in denen eine Serveranwendung in ein bestehendes System integriert werden muss, und dann zwei Anwendungen da sind die beide MySQL oder Postgres oder sonstwas benutzen.
Zuguter letzt gibts noch die Systeme mit den Embedded DBs. Und zu denen zählt mein System.
Noch wichtiger und von Dir (glaube ich) noch nicht bedacht, wie möchtest Du denn auf Änderungen am Datenbankschema reagieren?
Doch doch, bedacht habe ich das schon. Und um da äußerst flexibel zu sein, dachte ich da an einen Datenexport und -Import der bei einem Systemupdate gefahren wird. Das ist zwar etwas Aufwand, aber 1. Ich hab ein unabhängiges Backup der Daten (CSV, XML oder wie auch immer) und 2. ich kann mit der nächsten Version des Servers wenn ich will eine ganz andere Persistenz-Technik einsetzen. Bin also "etwas" flexibler.
Für eine Serveranwendung sieht das natürlich nicht anders aus. Auch hier kannst Du eine Installationsroutine vorsehen, welche die Tabellen anlegt.
Ich denke sowas in der Art werde ich auch umsetzen. Eclipselink kann ja alternativ zum anlegen der Tabellen in der DB ein SQL-Script erstellen. Am besten wäre es halt, wenn man das außerhalb der Serveranwendung triggern könnte, so dass man es in einen Maven-Build-Prozess mit einbaut:
1.) Serveranwendung compilieren und das fertige Anwendungspaket vorbereiten
2.) DB Schema aus den bestehenden Entities extrahieren und SQL-Script anlegen
3) Artefakte aus 1) und 2) zusammen mit einem Installer verheiraten. Fertig.
Das einzige was mich daran stört: Die Serveranwendung ist modular und kann zur Laufzeit mit weiteren Modulen (von Dritten) nachgerüstet werden. Und diese Module können auch Entities haben. Und hier schlägt dann wieder das "Problem" zu: "Create if not already exist"....(was so von Eclipselink nicht vorgesehen ist :-( ).
Vielleicht finde ich für diesen Anwendungsfall doch noch 'nen Weg der die Fehlermeldung von wegen "Du Trottel, die DB existiert schon" verhindert...
Gruß
Alex
P.S.
@Rail
Ja, das wäre eine Idee...Auch für das Nachrüsten von Modulen. Ein Upload via Webpage der die Tabellen anlegt, anpasst, und dann das Modul im Server deployed.
[update]
Hab gelesen Hibernate kennt einen "update" Modus der das Schema sogar "aktualisieren" kann. Eclipselink hingegen kennt sowas gar nicht. *sehr schade*
Was mich aber noch mehr irritiert: Eclipselink kann das Schema in eine SQL-File schreiben.... Hatte ich ja schon erwähnt. Aber wo braucht man sowas zur Laufzeit?! Ich mein: Nehmen wir mal an wir haben einen JEE Server der Eclipselink benutzt. Und ich deploye ne neue Anwendung die ihre eigenen Entities mitbringt. Hier wäre in der Tat so eine Update-Funktion sinnvoll. Das Schema dann in eine SQL-File schreiben zu lassen bringt einen (im Betrieb) nicht weiter. Denn ich will ja die Tabelle haben. Und spätestens wenn die Anwendung undeployed und mit einer neueren Version verseen wird, wäre eine Update-Funktion sinnvoll. Aber nein. Hier muss man entweder selbst hand anlegen (Update SQL-Files VOR dem deployen ausführen), ODER man spendiert noch mehr aufwand und bastelt sowas hier:
On Persistence: Running a SQL Script on startup in EclipseLink
Alles in allem: Ich denke für solche Szenarien könnte Eclipselink noch mehr tun. Nur bringt mich das jetzt nicht der Lösung näher :-(
