Viele Probleme lassen sich nicht durch einfache SQL-Queries lösen. Gerade wenn es um Daten-Generierung und Dinge geht, wo man die Logik nicht in allen Clients umsetzen möchte, die auch die Datenbank zugreifen.
Wärend Stored Procedures coole Dinge wie IF, WHILE und so können, haben die doch oft einen schlechten Ruf, weil man dann ja nicht mehr Datenbank unabhängig wäre, wenn man anfängt diese zu verwenden. Aber am Ende wird man sowie so nie wirklich die Datenbank wechseln und sollte man das tun, dann eher von SQL zu NoSQL und da ist es dann auch egal, da man alles alle neu anpassen muss.
Eine einfache Procdure in MySQL:
DELIMITER \\
DROP PROCEDURE IF EXISTS exampleProcedure\\
CREATE PROCEDURE exampleProcedure()
BEGIN
DECLARE checkval INT;
SET expectedval = 0;
START TRANSACTION;
-- implement your logic here
IF checkval = expectedval THEN
COMMIT;
ELSE
ROLLBACK;
END IF;
END \\
DELIMITER ;
CALL exampleProcedure();
DROP PROCEDURE IF EXISTS exampleProcedure;
Es gibt auch die klassischen IN und OUT Parameter. Alles ganz einfach und schnell zu schreiben. Sieht ein wenig aus wie Pascal. ABER im Vergleich zu PL/SQL fehlen doch eine Datentypen wie RECORDs, um komplexere Datenstrukturen anlegen zu können oder direkter mit Tables arbeiten zu können. SELECT .. INTO ist nett, aber RECORDs machen es doch sehr viel einfacher und strukturierter.
Aber an sich kommt man damit zurecht und man sollte doch mehr davon und auch öfters Stored Procedures verwenden, um sich in einigen Teilen das Leben etwas leichter zu machen.
Ich habe PL/SQL immer gerne verwendet, auch wenn ich oft genug daran verzweifelt bin.
Die Differenz zwischen zwei Datumswerten in Tagen:
Java (LocalDateTime)
if(ldt1.isAfter(ldt2)){
days = Duration.between(ldt1.toLocalDate().atStartOfDay(), ldt2.toLocalDate().atStartOfDay()).toDays();
days = Math.abs(days);
}
Java (Date)
long days = TimeUnit.DAYS.convert(date.getTime() - date2.getTime(), TimeUnit.MILLISECONDS);
Wie man überall lesen kann will Oracle nun auch JEE gerne abgeben. Aber sie sichern zu weiterhin an Java festzuhalten.
In den meistens News klingt es so als wäre das ein Widerspruch in sich. Ich kann Oracle aber vollkommen verstehen. Der Java-Core ist so oder so OpenSource und JEE ist optional und kann durch andere Lösungen wie Spring ersetzt werden. Wie Standards wie JMS, EJB3 und so sind wirklich toll und funktionieren super. Sie werden auch viel genutzt, also kann man die auch nicht wirklich sterben lassen, gerade wenn man selbst damit viele Anwendungen gebaut hat.
Oracle auch wirklich viel mit Java gemacht und auch sehr gute Anwendungen damit entwickelt. Nur warum sollte man dafür im Besitz eine Standards sein? Als das alles noch bei Sun lag lief auch alles super und (jetzt folgt der wichtige Punkt) man musste sich nicht mit dem ganzen Drumherum rumärgern.
Als PHP Entwickler hat man ja auch nicht gleich Lust sich den PHP-Standard noch mit auf zu halsen.
Bei der Eclipse Foundation wäre JEE gut aufgehoben und Oracle kann weiterhin mit Java entwickeln und sich sogar einbringen ohne gleich für alles verantwortlich gemacht zu werden.
Ich bin jeden Fall gespannt wie es weiter geht und sehe da mehr Zuspruch in die Zukunft Javas von Oracles Seite als mögliches Abwenden von JEE oder gar Java an sich.
Nachdem ich im letzten halben Jahr mit Neo4j und nun auch mit Elasticsearch zu tun hatte, bin ich was NoSQL-Datenbanken angeht etwas zwiegespalten. Graphen-Datenbanken sind toll um Beziehungen zwischen Entitäten abzubilden. Dokumenten-orientierte Datenbanken wie Elasticsearch ideal um unstrukturierte Daten zu speichern und neben der eigentlichen Abfrage auch z.B. Durchschnittswerte oder Übersichten von der Abdeckung von bestimmten Attributen/Feldern gleich mit abzufragen.
Die Abfragen sind schnell. Aber.. auch sind die Queries komplexer (Neo4j) bis sehr viel komplexer (Elasticsearch). Der Vorteil der NoSQL Datenbanken ist, dass man schon fertige Objekte zurück bekommt und man nicht auf Tabellenstrukturen beschränkt ist. So kann man also Listen mit Objekten die zu einer Entität gehören gleich mit abfragen und erspart sich ein zweites Query und zusätzliches Mapping.
Aber sind die NoSQL Datenbanken wirklich so viel schneller, wie man immer hört? Dafür muss man verschiedene Dinge bedenken. Zuerst ob die Datenbank die primäre Datenquelle ist oder nur zusätzlich zu einem RDBMS verwendet wird. Ich hatte bis jetzt nur mit zusätzlichen Datenbanken zu tun. Deren Daten wurden durch Cronjobs aus dem RDBMS gelesen, aufbereitet und dann in die NoSQL-Datenbank geschrieben.
Entweder per CSV-Import (Neo4J) oder direkt über die REST-API (Elasticsearch). Die gleichen Abfragen waren in der MySQL-Datenbank langsamer. Nicht viel langsamer. Aber es war doch spürbar und lagen bei der Neo4J bei so 30%-40%.
Wenn man nun aber einberechnet wie viel Aufwand der Import darstellt, der bei beiden Anwendungsfällen zwischen 1,5-5min lag, sieht es schon sehr viel anders aus. Die Importscripte reduzierten die Datenmenge natürlich sehr extrem und schrieben nur die nötigsten Daten in die NoSQL-Datenbanken. Bei der Neo4J waren es wirklich nur Ids und Relationen. Die Elasticsearch hatte alle elementaren Felder und auch Unterobjekte, die bei SQL über Joins geladen werden würden. Auf dieser reduzierten und stark vereinfachten Datenbasis waren die Abfragen sehr schnell.
Wenn man mit ein paar SQL-Statements die selben Daten in der MySQL in dem selben Umfang in eigene Tabellen schreibt, ist die MySQL Datenbank meiner Erfahrung nach genau so schnell. Im Vergleich von MySQL und Neo4J muss man sagen, dass für die Abfragen plötzlich viel mehr Daten zur Verfügung stand und diese auf genutzt wurden. Außerdem wurden doppelt so viele Queries verwendet. Am Ende war die MySQL-Lösung langsamer aber auch sehr viel komplexer und in dem Sinne besser.
Ich für meinen Teil sehe in den NoSQL-Datenbank nur einen Vorteil, wenn man die Vorteile derer auch nutzt. Wenn ich keine Graphen brauche, brauche ich auch keine Neo4J-Datenbank. Habe ich nur Entitäten und DTOs die ich schnell speichern und laden möchte, brauche ich keine Elasticsearch. Elasticsearch ist komplex und kann ein paar wirklich interessante Dinge durch deren Aggregations. Wenn ich haufenweise unterschiedliche Daten aus vielen verschiedenen Quellen zusammen fahren möchte bin ich mit Elasticsearch gut beraten. Aber wenn ich nur Geschwindigkeit haben möchte muss ich nur die Datenbasis verringern und vereinfachen. Neo4J ist auch extrem Speicher hungrig. Was bringt es mir wenn ich 96GB an RAM brauche um das zu machen was ich mit 32GB und einer MySQL oder einer Oracle-DB genau so schnell hinbekomme. Wenn ich dann sehr viel RAM habe und ganze Datenbanken im Speicher halten kann, habe ich die selbe Geschwindigkeit und bin mit der größeren Datenbasis sehr viel flexibler. Außerdem ist alles schneller und sicherer was ich direkt innerhalb der Datenbank machen kann. Ein Import von der MySQL in die Neo4J brauchte viel darum herum um sicher zu sein. In einer Oracle würde alles sowie so in einer Transaction laufen, die auch nicht noch den Server der das Script startet belastet.
Wer also in seinem RDBMS Performanceprobleme hat, soll sie auch dort lösen und nicht glauben, dass ein weiteres System anzubinden (und synchron zu halten) dieses Probleme lösen würde.
Gerade in Firmennetzwerken kann man nicht immer wie man gerade will eine VM ins Netzwerk hängen. Oft hat man aber Bedarf an einer VM. Gerade wenn man auf Windows entwickelt und am Ende auf Linux deployen soll, ist es immer gut eine Linux-VM zur Hand zu haben, um schnell selbst testen zu können, ob da noch alles läuft.
Auch fertige VMs wie die von Oracle mit einer fertig installierten Datenbank sind wirklich praktisch und können in vielen Situationen helfen.
Um jetzt aber einen eigenen Server in VM zu betreiben, von dem man vom Host aus zugreifen kann, aber kein anderer Rechner im Netzwerk diesen Server sehen kann, kann man in VirtualBox ein Host-only Netzwerk erstellen. Der Host ist Teil des Netzwerks, aber er Rest ist rein virtuell.
Beim einfachen Anlegen einer VM ist immer NAT voreingestellt.
Zuerst muss man das Host-only Netzwerk erstellen.
am Besten mit DHCP damit man sich nicht mit den IP-Adressen herum ärgern muss.
Danach die VM von "NAT" auf "Host-only" beim Netzwerkadapter umstellen.
Wenn man nun die VM wieder startet sieht man schon dass die IP sich geändert hat
In den letzten Tagen liest man immer mehr, dass sich viele Sorgen um die Zukunft von Java und gerade um Java EE machen. Wie schon vorher bei JavaFX gilt auch hier immer der Vorwurf Oracle würde sich nicht genug einbringen und auf Fragen um die Zukunft nicht weiter äußern. Oracle ist leider nicht Sun und da sie keine Rechte an der API gegenüber Google mit Android geltend machen konnten, scheint wohl das Interesse noch Mals wieder gefallen zu sein.
Die nächsten Jahre wird man sich um Java sicher keine sorgen machen müssen. Java ist immer noch mit die wichtigste Plattform für Enterprise Entwicklungen und die angebotenen Lösungen sind sehr mächtig und nehmen einen vielen wichtigen Bereichen eine Position ein, bei denen man nicht einfach mal schnell eine andere Lösung einführen kann.
Auch wenn Oracle selbst das Interesse verlieren sollte, gibt es immer noch genug eine große Mitspieler, die Java nicht so einfach sterben lassen würden. IBM, Apache und Red Hat sind die wichtigsten hierbei. So lange diese hinter Java stehen und Eclipse und Jetbrains entsprechende Entwicklungsumgebungen anbieten, werden sich viele sehr zurück halten auf etwas anderes umzusteigen und wo ein Markt ist werden auch Firmen sein, die diesen Markt bedienen. Wenn Oracle nicht mehr Teil dieses Marktes sein will, dann soll es eben so sein. Wichtige Entwicklungen wie Microservices und alternativen zu Node.js kamen am Ende ja auch nicht von Oracle sondern von anderen Anbietern. Oracle ist Besitzer von Java aber die Java-Welt wird meistens von anderen Bestimmt.
Aber ähnliches hat man auch lange über Zend gehört.. aber jetzt ist man bei PHP 7.0 und auch wenn es lange dauerte, zweifelt wohl niemand mehr an der Zukunft von PHP. Genau so wird es bei Java sein, es mag mal Zeiten geben wo es langsam voran geht, aber solange von Außen der Input bleibt wird es weiter gehen und am Ende ging es mit Java immer voran.. wenn auch zu vor schon oft eher langsam.
Im Serverbereich ist Java sehr stark und wird es sicher auch noch viele Jahre bleiben.
"Ich habe mit Oracle-DB gearbeitet und musste dort Konstrukte drin bauen, die einen 2 Tage Arbeitszeit und tausende Nerven gekostet haben und man 4 mal pro Stunde an sich selbst gezweifelt hat. Manchmal war einem am Ende nicht mal ganz klar, warum es nun wirklich doch funktionierte.
Jetzt arbeite ich mit MySQL/MariaDB... und wünsche mir oft die Oracle-DB zurück, weil ich damit diese Konstrukte überhaupt bauen konnte!"
Mein Kommentar dazu, wenn mal wieder über Oracle und deren doofe DB geweint wird.
Wer mal curl benötigt aber gerade nur Windows zur Verfügung hat, kann es sich leicht nach installieren. Oracle hat eine gute kleine Anleitung veröffentlicht.
Bei mir reichte es dir Schritte 3 und 4 auszuführen.
Ein wenig besinnliches zu Weihnachten. Performance-Analyse auf Oracle Datenbanken. Wenn man heraus finden will welche SQLs viel Zeit verbrauchen, kann man das Query hier verwenden. Es ist ein erster Ansatz und keine absolute Lösung. Aber wenn man Probleme hat, ist es ein guter Einstieg in die Analyse.
select ROUND(disk_reads/decode(executions,0,1,executions)/300) EXTIME, SQL_TEXT
from v$sql
where disk_reads/decode(executions,0,1,executions)/300 >1
and executions>0
order by (disk_reads/decode(executions,0,1,executions)/300) DESC
Oft hilft es am Ende einfach einen Index zu setzen. Aber manchmal muss man tiefer in die Materie gehen.
A few month ago, i wrote a post about the situation between JavaFX and HTML5 and their positions in the fight for the next leading GUI-technology in the Java world. I said, JavaFX is only interessting to improve existing Swing application but not the right thing for the developing new applications.
I can fully agree to this point of view. There are greater problems than the technological difficults and the few bugs and problems with the implementation of some JavaFX parts. The greatest problem is the missing support by Oracle. JavaFX for mobile devices is only supported through 3rd party solutions like RoboVM. Scene Builder is not very stable or bugfree. With only simple changes in a FXML, you can cause troubles that Scene Builder is not able to ... it crashes or only shows an empty screen.
You have to wait month for new versions or simple bugfixes.
Oracles own applications use Swing or are webbased. The change from Swing to JavaFX was often proclaimed, but never came to the surface or was visible in any other way. Swing has an extensive repository of mature and feature-rich components. It isn't easy to replace them in a short time range. A simple migration isn't that simple and would took a lot of work. You know that you can open JavaFX scenes in a SWT application. I used it, but it isn'T realy a good integration. It is only a canvas, where the JavaFX scenes is drawn on. No real interactions between the two worlds. It like the WebView in JavaFX. Yes you could write an application in HTML and JavaScript an use JavaFX as an wrapper.. but.. why? An IE11 should be a better solution than this.
The usage of Swing disappeares slowly, but there no new JavaFX applications to repalce them. There are a few JavaFX fans, but i think they only exist, because Swing is deceasing. Since i begin to programm in Java i wrote a few Swing applications and the first contact with JavaFX was more than disillusioning. Netbeans + Swing working great and every thing works very well. Scaling of the GUI works good. In JavaFX you can implement it too, but it isn't as intuitive as with Netbeans. The CSS-implementation in JavaFX is not comparable with the CSS we know from HTML.
Why JavaFX 2 wasn't accepted well? In my oppion, the reputation was bad, the support was insecure in version 1.0.
When version 2.0 arrives, most developers found a other or better solution with better support and more promising future. So the support from the developer-side was missing and without this every thing only works on a minimal level to save the resources for more promising projects.
JSF 1.x wasn'T that good, but there was no doubt, that it will be supported an new version will be developed. I think that Apache supported JSF, was a big advantage. And the newest versions are great. Maybe JavaFX can go the same way with more support.
So i support the conclusion: If oracle will invest more resources in JavaFX more developers show interest and so it could be a future with JavaFX.
I can't understand the fear that without JavaFX the JEE market could be damaged or it can lose it's impact in the developer-environment. Node.js could be a threat, more than php, but in the last years the JEE-market grow with microservices, middleware-services for android-apps, reactive-development and frameworks like node.js. REST-services, web-portale-solutions, small containers, websockets und push-services in the Tomcat servlet-container. Very nice and the movement doesn't stop till now. The big Topics of the last years.. Desktop-GUIs wasn't a topic. And with the great Java webframeworks, HTML5 and AngularJS the client-side won't be losed. JEE and Web-Clints work great together.
The lose of a few desktop application won't hurt, when you get new shiny web-application based on Java technology.
Vor ein paar Monaten hatte ich einen Post über JavaFX und die Konkurrenz zu HTML5 geschrieben. Und dabei das Fazit gezogen, dass JavaFX gut ist um vorhandene Swing-Anwendungen zu erweitern und in Zukunft zu modernisieren, aber für Neuentwicklungen ich eher eine andere Technologie nutzen würde.
Jetzt gab es bei JAXenter den Artikel Ruhe in Frieden JavaFX, wo ähnliches Thematisiert wird.
Die dort angesprochenen Punkte kann ich meiner Erfahrung nach voll zustimmen. Die technischen Unzulänglichkeiten und Probleme sind nicht mal das eigentliche Problem, denn die Unterstützung von Oracle scheint wirklich kaum vorhanden zu sein. Mobile-Unterstützung gibt es nur dank der RoboVM. Der Scene Builder ist relativ instabil und durch händische Anpassungen schnell aus dem Tritt zu bringen. Updates und neue Versionen, die das Problem beheben, waren bis Sommer jedenfalls nicht verfügbar gewesen.
Die Programme von Oracle setzen auch jetzt meistens noch auf Swing und nicht auf JavaFX. Der große Wechsel wurde zwar an vielen Stellen beschworen, aber war nie sichtbar. Swing hat auch zum Großteil sehr ausgereifte Komponenten und die Anwendungen sind über viele Jahre gewachsen... da ist ein schneller Wechsel nicht möglich und eine einfache Migration ist auch nicht machbar. Anwendungen komplett auf JavaFX umzustellen ist viel Arbeit. Ich habe gesehen, dass man gut SWT und JavaFX in einer Anwendung verwenden kann, aber wenn man es nüchtern betrachtet, wird auch nur eine JavaFX GUI irgendwie in SWT rein gezeichnet. Eine echte Integration gibt es nicht. 2 Welten die in einer Anwendung existieren.
Es gibt also weniger Swing, aber nicht mehr JavaFX. Es gibt ein paar JavaFX Verfechter, die es aber wohl auch nur gibt, weil Swing ja irgendwie abgekündigt wurde. Ansonsten wären alle wohl einfach bei Swing geblieben. Ich habe auch seit meinen Anfängen in Java ein paar Swing-Programme geschrieben und empfand den ersten Kontakt mit JavaFX als sehr ernüchternd. Netbeans + Swing funktioniert einfach sehr gut und auch das skalieren der GUI-Element funktioniert relativ gut. JavaFX kann es zwar auch, aber die Bedienung ist hier weniger selbsterklärend und das CSS ist weit von dem entfernt, was man sich erhofft hatte und aus dem Web-Bereich gewohnt ist.
Das mit der Version 2 von JavaFX kein großer Anstieg der Nutzerzahlen kam, liegt meiner Meinung auch daran, dass JavaFX einen schon sehr schlechten Ruf hatte und Jahre auf der Kippe stand.
Als dann eine brauchbare Version kam, hatten die meistens sich schon anderweitig umgesehen und etwas mit Zukunft und größerer Unterstützung gewählt. Das Problem ist damit eben, dass JavaFX dadurch nicht mehr die Unterstützung bekommt, um weiter wachsen und sich entwickeln zu können. So wird alles auf einem minimal Level betrieben. Wenige Nutzer.. wenige Entwickler.
Betrachtet man dagegen JSF was mit der Version auch nicht das Gelbe vom Ei war, aber immer offizielle Unterstützung bekam (auch von Apache) und somit man auch Vertrauen in die Zukunft hatte, das sich gerade mit den neusten Versionen auch als gerecht fertig erwiesen hat. Vielleicht würde auch JavaFX mit breiterer Unterstützung sich genau so gut entwickeln können.
Ich kann mich dem Fazit voll und ganz anschließen: Sollte Oracle nicht plötzlich viel in JavaFX investieren, sollte man lieber sich etwas mit mehr Unterstützung suchen und auf eine ungewisse Zukunft vertrauen.
Die Angst dass der Java EE Markt dadurch gefährdet wird. Node.js ist vielleicht eine größere Gefahr als PHP, aber die letzten Jahre basierte der Wachstum und die Stabilität von Java EE nicht auf Swing oder dem Desktop-Markt. Microservices, Android-Apps, Frameworks für Reactive-Entwicklung oder gleichwertige Lösungen als Alternative zu Node.js. REST-Services, Portale und kleinere Container. Auch die WebSocket und Push-Services im Tomcat. DevOps Lösungen. Alles tolle Entwicklungen im Java-Bereich.. es gab viel Bewegung und Fortschritte, aber keiner davon hing groß mit der Entwicklung von Desktop-Clients zusammen. Ich glaube der Rückgang bei den Desktop-Clients ist normal und Dank Java Web-Frameworks, HTML5 und AngularJS oder ähnlichen Frameworks, muss sich die JEE-Welt keine Sorgen machen.
Aber ich fühle mich gerade sehr in meinen Ansichten und Äußerungen von vor einem halben Jahr sehr bestätigt :-)
Blog-entries by search-pattern/Tags:
Möchtest Du AdSense-Werbung erlauben und mir damit helfen die laufenden Kosten des Blogs tragen zu können?