Oracle oder SQL-Server

[java007]

Hallo Leute,

ich würde gerne die Vor- und Nachteile der beiden Datenbankmanagementsystemen (Oracle und SQL-Server) in Verbindung mit Java erfahren. Im Weiteren würde ich gerne wissen ob die Oracle Express Edition(kostenlose edition) eine verbindung zu Java unterstützt. Würde mich auf Tipps freuen.

MFG

Gruß

 

[Sanix]

Java muss die Datenbanken unterstützen nicht umgekehrt. JDBC zu Oracle gibts und funktioneirt auch einwandfrei.
SQL-Server meinst du den von Microsoft?

 

[java007]

ja ich denke schon

 

[kama]

Hallo,

Im Weiteren würde ich gerne wissen ob die Oracle Express Edition(kostenlose edition) eine verbindung zu Java unterstützt. Würde mich auf Tipps freuen.

Du kennst die Lizenzbestimmungen für die Oracle Express Edition ? Abgesehen davon kann Java auch wunderbar mit der OED kommunizieren...Die Unterschiede zu einer "richtigen Oracle" sind nicht wirklich groß (OED kann max. 5 GB Daten...)...

Wo liegt denn genau Dein Problem ?

Warum kein PostgreSQL oder MySQL ?

Gruß
Karl Heinz Marbaise

 

[maki]

Oracle kennt Sequenzen, MS-SQL Server arbeitet nur mit IDs.
Die Installation ist beim MS-SQL Server um einiges einfacher (ca. 5-mal "Next" klicken), MS-SQL Server kann aber eben nicht alles was nützlich ist, zB. die ID eines Datensatzes manuell zu setzen setzt zwingend eine abgeschlossene Transaktion für die betroffene Tabelle voraus (nervt zB. mit DBUnit), und beim wiederherstellen eines Backups auf einem MS-SQL Server muss man ein paar Stored Procedures kennen, sonst wird das nix

 

[java007]

Vielen Dank für die Infos, ich arbeite an einem Projekt für das ich im kurzen eine Datenbank erstellen muss. Für die enge Wahl habe ich Oracle und SQL-Server vorgesehen, demzufolge wollt ich gern von erfahrenen-Anwendern die Hauptfunktionen dieser gerne erfahren

MFG

 

[megachucky]

Was für ein Projekt ist das denn? Mein erster Eindrück würde jetzt sagen: Uni-Projekt oder kleine J2SE-Desktop-App. Da würde ich einfach eine MySQL-Datenbank nehmen (am einfachsten mit Xampp installieren)...

 

[MrWhite]

@maki
Dein Post hoert sich ein wenig biased zu Gunsten von Oracle an.

Oracle kennt Sequenzen, MS-SQL Server arbeitet nur mit IDs.

Das mag schon sein. Die Arbeit mit Sequenzen ist aber viel muehseliger als mit AutoNumber, in Oracle braucht man fuer alles einen Trigger.

...und beim wiederherstellen eines Backups auf einem MS-SQL Server muss man ein paar Stored Procedures kennen, sonst wird das nix

Und bei Oracle ist das fast schon eine Wissenschaft fuer sich. Oracle ist auch da wesentlich komplizierter.

 

[kama]

Hallo,

Das mag schon sein. Die Arbeit mit Sequenzen ist aber viel muehseliger als mit AutoNumber, in Oracle braucht man fuer alles einen Trigger.

Seit wann ? Wo ist das Problem mit den Sequenzen in Oracle ?

CREATE SEQUENCE seq_tabelle1;

INSERT INTO tabelle1 (num, name) 
VALUES (SEQ_TABELLE1.nextval, 'Test');

Ja ok...das einzige worauf man achten muss ist, dass man eben für jede Tabelle (oder je nach Bedarf) eine eigene Sequence anlegt...das wars aber auch...

Klar kann in Oracle noch einige andere Dinge machen...aber die braucht man meinst nicht...

EDIT: Noch vergessen. In Java brauch ich mir darüber keine Gedanken mehr zu machen...da nutze ich dann Hibernate und bin das Problem los...egal ob Oracle, MySQL, PostgreSQL etc.

EDIT: Der Restore eine DB ist immer eine Wissenschaft...da man alles korrekt herstellen muss...

Aber wofür braucht man denn einen Trigger in Oracle ?
Gruß
Karl Heinz Marbaise

 

[MrWhite]

Wenn du standardkonformes SQL in deiner Applikation und keine Zwischenschicht ala Hibernate verwenden willst, dann wirst du Trigger zur PK Generierung fuer Oracle zwingend benoetigen. Mal abgesehen davon, dass Sequenzen viele Probleme mit sich bringen koennen, vor allem bei Migrationen oder Backups.

Und wenn mir jetzt einer mit Natural Keys kommt, der bekommt was auf den Deckel!

 

[kama]

Hallo,

Wenn du standardkonformes SQL in deiner Applikation und keine Zwischenschicht ala Hibernate verwenden willst,

Warum sollte ich mir das antuen und SQL noch selbst schreiben.....wozu gibt es denn Hibernate (und andere)...

dann wirst du Trigger zur PK Generierung fuer Oracle zwingend benoetigen.

Wenn ich dass machen würden, dann ja...aber wozu.....es gibt doch Hibernate...also warum soll ich mir das Leben schwerer machen als nötig...

Mal abgesehen davon, dass Sequenzen viele Probleme mit sich bringen koennen, vor allem bei Migrationen oder Backups.

Migration ? Hm...Wenn ich das mit Hibernate mache...dann ändere ich eine Konfigurationsdatei und generiere die Anlage Skripte (Anlegen Tabellen etc.) einmal neu und das wars....Lese die alten Daten und schreibe Sie in die neue DB weg......ich finde es geht nicht einfacher...

Backup? Hm...ist mir nicht klar. Im Gegenteil...ich kann die Sequenzen einzeln einstellen und kann damit sogar alte Stände in eine Vorhandene DB einspielen (Indizierung anschmeißen und das wars)....was mit anderen Mechanismen nicht machbar ist...

Ich gebe Dir recht, wenn wir jetzt mit Tablespaces/Index-Spaces etc. anfangen dann wird es richtig kompliziert...aber das ist dann Aufgabe der Oracle-DB-Admins...und nicht mehr meine...;-)

Gruß
Karl Heinz Marbaise

 

[MrWhite]

Hallo,

Warum sollte ich mir das antuen und SQL noch selbst schreiben.....wozu gibt es denn Hibernate (und andere)...

Wenn ich dass machen würden, dann ja...aber wozu.....es gibt doch Hibernate...also warum soll ich mir das Leben schwerer machen als nötig...

Du hast gut Reden. Fuer 08/15 Standardapplikationen ist das vielleicht wahr. Viele andere Anwendungen oder auch Legacy Systeme benoetigen aber custom SQL. Allen voran Anwendungen, bei denen es auf Performance ankommt. Gerade bei grossen Insert-Selects braucht man custom SQL. Selig ist der, der in Greenfield-Environments 0815 Apps entwickeln darf.

Migration ? Hm...Wenn ich das mit Hibernate mache...dann ändere ich eine Konfigurationsdatei und generiere die Anlage Skripte (Anlegen Tabellen etc.) einmal neu und das wars....Lese die alten Daten und schreibe Sie in die neue DB weg......ich finde es geht nicht einfacher...

Backup? Hm...ist mir nicht klar. Im Gegenteil...ich kann die Sequenzen einzeln einstellen und kann damit sogar alte Stände in eine Vorhandene DB einspielen (Indizierung anschmeißen und das wars)....was mit anderen Mechanismen nicht machbar ist...

Was hat das denn mit Indizierung zu tun? Mit anderen Mechanismen, wie z.B. AutoColumns fuer Surrogatschluessel bei den meisten anderen RDBMBS, stellt sich so eine Problematik erst gar nicht! Wohingegen wir immer wieder Support Faelle haben, bei denen UNIQUE-Constraints verletzt werden weil mal wieder eine Sequenz aus der Reihe tanzt!

 

[maki]

@maki
Dein Post hoert sich ein wenig biased zu Gunsten von Oracle an.



Das mag schon sein. Die Arbeit mit Sequenzen ist aber viel muehseliger als mit AutoNumber, in Oracle braucht man fuer alles einen Trigger.



Und bei Oracle ist das fast schon eine Wissenschaft fuer sich. Oracle ist auch da wesentlich komplizierter.

Oracle ist eben auch eine echte Enterprise DB, im Gegensatz zum SQL Server

Das Problem mit den Sequenzen und Triggern verstehe ich nicht, JPA mit Hibernate oder EclipseLink lösen es elegant und Trigger habe ich nie gebraucht in Oracle, man kann natürlich Trigger / PL/SQL oder gar Java für Oracle schreiben, oder eben TSQL für den MS-SQL Server, aber auch da bietet Oracle mehr.

Und falls wir hier von Legacy Systemen sprechen, dann ist die DB doch eh meist vergebenen, wenn man Glück hat muss man keine ADABAS C Db mehr nutzen

Ja, die Oracle installation ist komplex, aber sehr gut Dokumentiert (um zB. die Konfiguration nach der Installation wieder zu korrigieren ).

Jedenfalls sind beide imho besser als MySQL, dann lieber Derby oder H2.

 

[kama]

Hallo,

Du hast gut Reden. Fuer 08/15 Standardapplikationen ist das vielleicht wahr. Viele andere Anwendungen oder auch Legacy Systeme benoetigen aber custom SQL.

Sorry ...aber ich habe schon systeme mit Hibernate Entwickelt die nun wirklich keine 0815 Applikationen waren und auch nicht sind...und jetzt kommt es wie es kommen musste...

Allen voran Anwendungen, bei denen es auf Performance ankommt.

Das Performance Argument....Da fällt mir nur ein....was nennst Du denn Performance?

Gerade bei grossen Insert-Selects braucht man custom SQL.

Komisch ich habe in Hibernate immer nur die SELECT's Untersuchen müssen...nie die Insert-Statements...da fehlte mal ein Index, da wahr mal ein JOIN nicht korrekt (falsches Mapping etc.)...oder nach fachlicher Analyse war dann die fachliche Verknüpfung nicht ok usw. Das hatte aber nichts mit Hibernate zu tuen sondern mit dem Grundlegenden Object-Modell....

Selig ist der, der in Greenfield-Environments 0815 Apps entwickeln darf.

Ich habe sowohl in Greenfield entwickeln dürfen (kleine App aber rechte Hohe Performance ansprüche)...und sehr große non Greenfield...

Wohingegen wir immer wieder Support Faelle haben, bei denen UNIQUE-Constraints verletzt werden weil mal wieder eine Sequenz aus der Reihe tanzt!

Das hört sich danach an, dass mal wieder ein technischer Schlüssel mit einem fachlichen Schlüssel gleich gesetzt wurde...abgesehen davon kann eine Sequence nicht aus der "Reihe Tanzen"...

Gruß
Karl Heinz Marbaise

 

[MrWhite]

Man merkt, dass ihr nie wirklich hohe Performance im Data-Tier gebraucht habt, geschweige denn viel Erfahrung damit habt.

Ich habe jetzt schon an mehreren Applikationen gearbeitet, bei denen Millionen von Records während Verarbeitungen rumgeschoben wurden. Da kommt man mit Hibernate einfach nicht weit.

Komisch ich habe in Hibernate immer nur die SELECT's Untersuchen müssen...nie die Insert-Statements

Man macht ja oft einen Insert into <table> ... select from ...

Das du diese Art und Weise der Datenverarbeitung mit SQL nicht kennst, bestätigt nur meine obige Bemerkung. Und Hibernate ist teilweise nunmal einfach eine Performance-Krücke!

 

[kama]

Hallo,

Man merkt, dass ihr nie wirklich hohe Performance im Data-Tier gebraucht habt, geschweige denn viel Erfahrung damit habt.
Ich habe jetzt schon an mehreren Applikationen gearbeitet, bei denen Millionen von Records während Verarbeitungen rumgeschoben wurden. Da kommt man mit Hibernate einfach nicht weit.

Ich habe ja gefragt, was Du unter Performance verstehst ? Die Frage hast Du aber nicht beantwortet...abgesehen davon Millionen von Record rumgeschoben habe ich auch (ca. 20 Millionen)...Die entscheidende Frage dabei ist: In welcher Zeit?

Man macht ja oft einen Insert into <table> ... select from ...

In einer Business App...? Noch nie gesehen....habe ich lediglich in Hand-Gestickten Scripten gesehen...aber nicht in einer Applikation....Das zeugt mehr davon, dass das Design der App nicht in Ordnung ist...

Das du diese Art und Weise der Datenverarbeitung mit SQL nicht kennst, bestätigt nur meine obige Bemerkung.

Reichlich komisch Dein Ton....

Und Hibernate ist teilweise nunmal einfach eine Performance-Krücke!

Mir Zeigt diese Aussage, dass Du kaum oder garnicht mit Hibernate gearbeitet hast...Da man in Hibernate, wenn es denn wirklich nötig ist auch entsprechende SQL Statements selbst machen kann...

Gruß
Karl Heinz Marbaise

 

[MrWhite]

Mir Zeigt diese Aussage, dass Du kaum oder garnicht mit Hibernate gearbeitet hast...Da man in Hibernate, wenn es denn wirklich nötig ist auch entsprechende SQL Statements selbst machen kann...

Klar, das nennt sich dann Native Query. *g*

Ich habe ja gefragt, was Du unter Performance verstehst ? Die Frage hast Du aber nicht beantwortet...abgesehen davon Millionen von Record rumgeschoben habe ich auch (ca. 20 Millionen)...Die entscheidende Frage dabei ist: In welcher Zeit?

Schneller als mit Hibernate. Wir haben hier eine Gesamtverarbeitung mit Hibernate und das ist eine Krücke. Braucht ungefähr 20h. Das kann man mit einer Sammlung nativer Queries in 2h durchführen. Hibernate ist halt einfach nicht besonders gut darin, Millionen Entities zu erzeugen.

In einer Business App...? Noch nie gesehen....habe ich lediglich in Hand-Gestickten Scripten gesehen...aber nicht in einer Applikation....Das zeugt mehr davon, dass das Design der App nicht in Ordnung ist...

Erzähl mir nix, ich arbeit jetzt lange genug mit großen Datenmengen. Ich weiss, wie man so eine Applikation aufbaut.

 

[kama]

Hallo,

Klar, das nennt sich dann Native Query. *g*

Das ist nur eine von vielen Möglichkeiten...
HQL ist ein andere, die unterschiedlichen Caches und auch die entsprechenden Fetch-Strategien sind andere Möglichkeiten...und sehr oft auch die Applikation selbst...für Große Mengen gibt es auch Batch-Inserts/Updates etc.

Schneller als mit Hibernate. Wir haben hier eine Gesamtverarbeitung mit Hibernate und das ist eine Krücke. Braucht ungefähr 20h. Das kann man mit einer Sammlung nativer Queries in 2h durchführen. Hibernate ist halt einfach nicht besonders gut darin, Millionen Entities zu erzeugen.

Hm...Die 20 Millionen wurden in ca. 2 h (2 h 12 Min) Verarbeitet...Da war nicht nur die Erzeugung sondern auch die Verarbeitung in einer App mit komplexen fachlichen Prüfungen und Relationen zu bewerkstelligen...alles in einer J2EE Anwendung....also als Langsam würde ich das nicht bezeichnen...mit den 20 h haben wir auch angefangen...(die ersten fachlich korrekten implementierungen)...nach drei Optimierungszyklen waren wir dann bei 3 h und nach dem vierten dann bei den genannten Zeiten...

Erzähl mir nix, ich arbeit jetzt lange genug mit großen Datenmengen. Ich weiss, wie man so eine Applikation aufbaut.

Interessantes Statement...kann ich genauso sagen ;-)

Gruß
Karl Heinz Marbaise

 

[MrWhite]

Das ist so pauschal doch gar nicht vergleichbar, da spielen viel zu viele Faktoren mit rein.

Hibernate kann jedenfalls meines Wissens nach kein performance-steigerndes DDL ohne einen Nativen Query ausführen (z.B. Index-Drops vor großen Inserts etc.). Da muss manuell DDL geschrieben werden. Mit Hibernate-Bordmitteln ohne natives SQL erzielt man in meinen Anwendungsbereichen kaum akzeptable Performanz.