Der claim ist mir etwas zu plakativ!
SQL ist eine weitere Sprache im Portfolio. Nicht mehr und nicht weniger.
Das der No-SQL Boom nicht lange anhält war mir schon recht früh klar: Es gibt bestimmte Anwendungsgebiete, für die NoSQL sinnvoll ist, aber im Normalfall ist eine relationalen DB die bessere Wahl.
Aber wenigstens habe ich wieder ein neues Buzz-Wort gelernt…
bye
TT
Mit besser verstehen hat das wohl weniger zu tun. Sondern eher mit mögen. 
wenn man diesem Kollegen glaubt sollten Java-Entwickler gar keinen SQL-Code schreiben:
https://community.oracle.com/docs/DOC-990968
bye
TT
[QUOTE=Timothy_Truckle;127213]wenn man diesem Kollegen glaubt sollten Java-Entwickler gar keinen SQL-Code schreiben:
[/QUOTE]
Das ist nur ein weiterer Versuch Oracles noch mehr Firmen an Oracle als RDBMS zu ketten 
Java-Entwickler schreiben auch zu wenig Scala-Code :ka:
Hab mir den ganzen Krams jetzt nicht durchgelesen - und mich als Hobby-Bastler wird es vermutlich auch nicht von Belang sein. Ich bastel mir weiter meine paar Abfragen zusammen und fertig. Aber als Big-Player würd ich erstmal die Gegenfrage stellen: Warum sollte ich? Mit folgendem Hintergrund: es gibt fertige Baukasten-Module (siehe SAP) die bestimmte vordefinierte Aktionen durchführen und ein bestimmtes Ergenis liefern die ich in Lego-Manier nach meinen Bedürfnissen zusammenstecken kann ohne auch nur ein SQL-Command selbst schreiben zu müssen. Macht man das mal noch ein wenig abstrakter und setzt vor den Code einen GUI-Builder der mir dass sogar noch genau so einfach ermöglicht wie gesagt - und dahinter ne gute Engine die das drauf hat - dann muss ich GAR NICHTS mehr selbst schreiben sondern zieh mir die Module wie benötigt zusammen - FERTIG.
Spart Zeit, damit Geld - und wenn richtig umgesetzt - auch nur sehr gering in Punkto Fehleranfälligkeit (halt z.B. Prüfung ob Baustein X an dieser Position überhaupt Sinn macht und ob Parameter und return zum Rest passen oder nicht).
Statt also 10 Bastler einen bestimmten Prozess umsetzen zu lassen setze ich nun einen Praktikanten ran der am Tag nach Schema F mal eben 10 Prozesse mit nem klicki-bunti-Baukasten zusammenklebt.
Daher also : Will ich denn überhaupt den SQL-Code selbst schreiben und kann ichs mir auch leisten? Oder sogar noch das Debugging ? Die Rechnung geht sehr schnell in genannte Richtung.
Hat also ganz sicher nichts mit “besser verstehen” zu tun, sondern damit dass es mitlerweile sehr einfach ist ohne viel selbst machen zu müssen. Nach der Aussage würde jeder einen Base64 selbts implementieren da er ja nicht versteht wie man Libs nutzt - so ein absoluter Bullshit.
Ich denke, Du hast das Problem noch nicht verstanden:
Solange es nur um simple “insert/update/delete”-Aktionen geht und vor allem keine Änderungen am Datenmodell erforderlich werden ist das von Dir vorgeschlagene Verfahren sicher gut anwendbar.
Aber schon wenn das Datenmodell etwas komplexer wird ist das verfahren nicht mehr so simple einzusetzten. Dabenötigen auch die meißten Frameworks OR-Mapping-Frameworks Unterstützung vom Entwicker in form von handgestricktem SQL (manchmal versteckt durch eine frameworkeigene Metasprache).
Und spätestens wenn Änderungen am Datenmodelll sich durch Deine gesamte Anwendung ziehen müssen, obwohl sie eigentlich keine Auswirkungen auf Deine GUI haben, wird das Problem deutlich. (Beispielsweise, wenn sich rausstellt, dass eine der Tabellen in eine zusätzliche 1-n-Beziehung aufgespalten werden muss.
Ich persönlich finde den Ansatz non NoSQL ziemlich charmant. Als Java-Entwickler betrachte ich die DB als “BlackBox”. Dort, wo ich bisher SQL-Abfragen gemacht habe rufe ich eine DB-Prozedur auf, die mir ein gut verarbeitbares Stream-Format (beispielsweise XML oder ein JSON) zurück liefert und ich arbeite weiterhin nur mit Java-Objekten. Das Datenmodell aus dem mein Strem generiert wurde interessiert mich nicht die Bohne.
In der Konsequenz können sich SQL- und Datenbank-Experten darum kümmern, wie die Daten in der DB organisiert sind und mit höchst möglicher Performanz geändert und ausgeliefert werden können.
Was derzeit fehlt, und was auch dringend erstellt werden sollte sind Frameworks, die diesen Ansatz für “point and click”-Programmierer wie Dich unterstützen.
Das Ganze als “Bullshit” abzutun ist auf jeden Fall nicht zielführend.
bye
TT
Tja, dann muss ich zugeben, hab ichs scheinbar wirklich nicht verstanden, aber wie gesagt: habs mir auch nicht durchgelesen. Ich hab halt erstmal nur den Titel gelesen und mir gedacht: WTF? Warum?
Nein, mal erlich: warum wird denn gezielt Java angesprochen? Machen es andere Sprachen etwa besser? Glaube ich kaum, denn auch dort stellen die Treiber ja erstmal nur den Link zur DB - die Arbeit mit der DB selbst in Form der SQL-Statements bleibt weiter am Programmierer hängen. Auch weis ich nicht wirklich was mit “wenn sie die Technologie besser verstehen würden” gemeint sein soll. Ich hab da ne DB die ich mit SQL ansprechen kann. Toll. Und? Was solls mir weiter bringen? Ich finds ja auch schon toll wie er weiter unten in diesem Post auf eine Hersteller-spezifische Sache anspielt. Will er mir jetzt damit sagen: Nutze diese DB, weil man damit X machen kann!? Was soll das? Wenn ich bock drauf hab meine Abfragen zu optimieren und gewisse Last von meinem Code in die DB auszulagern in dem ich entsprechend Abfragen schreibe oder gleich als Prozedur auf der DB hinterlege - dann komm ich ja nicht drumrum mich mit genau meiner genutzten DB auseinander zusetzen. Das hat dann aber auch schon nichts mehr mit Standard-SQL zu tun sondern wird sicher meistens auf Hersteller-spezifisches hinauslaufen. Was hat es denn dann noch bitte damit zu tun ob ich “die Technologie SQL besser verstehe”?
Bzgl. des point-and-click: soll ja nicht mal abwertend gemeint sein, und was Generatoren so erzeugen ist meist ziemlicher Schrott. Aber es vereinfacht die Bearbeitung und beschleunigt sie. Und wenn ich mir als großer Konzern überlegen muss ob ich da 10 “Profis” ransetze die mit trail-and-error mühsam einen Prozessschritt nach dem anderen zusammenbasteln, oder halt nur n Praktikant der das mit ner GUI “zusammenklickt” weis ich doch genau wie ich rechne. Weil die 10 Profis kann ich mir nicht leisten, den Praktikanten schon. Und wenn ich dann EINMAL eine Lizenz für ein Optimierungstool zahle geht die Rechnung leider in Richtung Praktikant - der dann als Obolus vielleicht noch n Kaffee bekommt.
[quote=Sen-Mithrarin]Nein, mal erlich: warum wird denn gezielt Java angesprochen?[/quote]Weil das “J” in “JAXenter” für “Java” steht?
Der Link von mir nennt übrigens gar keine Sprache für den “remote application”-Teil außerhalb der DB…
bye
TT
Wenn ich der Hersteller eines Tools wäre, dass Javaentwicklern die Möglichkeit gibt Datenbank-Statemnts in einer DSL zu schreiben, die SQL 1-zu-1 abbildet und zusätzliche Typ,Type-Safety bietet, dann würde ich mir auch wünschen, dass mehr Javaentwickler SQL verstehen und schreiben. Da wird die Zielgruppe für mein Tool größer.
Hier mal auf der Startseite klicken und den Lukas aus dem Artikel wiederfinden.
jOOQ: The easiest way to write SQL in Java
Ich selbst bin ein wenig zwiegespalten. Das ist als Programmierer allerdings normal, da sich alles ständig weiterentwickelt, was vor kurzem noch utopisch, unrealistisch erschien ist heute Bullshit-Bingo und morgen State-of-the-Art und übermorgen ein Irrweg den man sich nicht erklären konnte.
Wenn man ein RDBMS einsetzt, dann muss man auch SQL können. Dort liegen die Daten. Das ist die Wahrheit. Diese muss man auslesen können um überhaupt zu verstehen warum nun an irgendeiner anderen Stelle bestimmte Dinge angezeigt werden nachdem die Daten durch x-Schichten gewandert sind.
Dennoch bevorzuge ich ORM, da SQL ab bestimmten Größenordnungen zu einem unwartbaren Moloch verkommt.
Es stellt sich allerdings viel mehr die Frage ob RDBMS überhaupt noch eine Daseinsberechtigung haben.
Die typischen Datenmengen, die vielerorts benötigt werden passen heute in den Arbeitsspeicher. Mit Programmen wie Hazelcast baut man sich ein Cluster. Serialisierung und Persistenz können dank SSD-Technologie und anderen Vorgehensweisen vernünftig gelöst werden.
Die ganze Logik programmiert man dann in der Programmiersprache seiner Wahl.
SAP Hana ist da ein Beispiel, wie das heute gelöst werden kann.
[quote=ionutbaiu]Es stellt sich allerdings viel mehr die Frage ob RDBMS überhaupt noch eine Daseinsberechtigung haben.[/quote]So würde ich die Frage nicht stellen, denn dann müsste sie eindeutig mit “ja” beantwortet werden. Schließlich ist auch das von Dir in’s Feld geführte SAP Hana auch “nur” ein RDBMS, halt nur im Speicher und auch da drunter brauchst Du ein klassisches RDBMS, wenn Deine Daten einen Stromausfall überleben sollen…
Außerdem ist es um die ganzen NoSQL-DBs verdächtig still geworden. Es sind eben doch nur ein paar Spezialanwendungen, die auf relationale Datenstrukturen verzichten können.
bye
TT
:daumen:
Eben, bei ORM ging es nie um Ignoranz, sondern um Bequemlichkeit.
Ansonsten bin ich wirklich einverstanden damit selbstgestrickte Standards wie PL/SQL komplett zu ignorieren, wer will schon Businesslogik in der DB haben und sich gleichzeitig an Oracle als einzig moegliches RDBMS zu ketten?
Oracle war ja auch die Firma die dachte es waere echt toll Java Direkt in der DB laufen zu lassen…
Der Hype hat ein bisschen hachgelassen, aber sie sind imemr noch wichtig und nicht durch RDBMS zu ersetzen je nach Anwendung, zB. BigData in einer RDBMS tut weh… 
Firmen wie Facebook und Google kombinieren schon lange No-SQL und RDBMS, manchmal braucht man konsistente Daten, manchmal nicht - dafuer aber immense Mengen…
[quote=maki]wer will schon Businesslogik in der DB haben[/quote]Also prinzipiell ist Business-logik an einer zentralen stelle ja nicht verkehrt. Und ob das dann der App-Server oder die DB ist könnte man schon fast als Geschmackssache definieren.
[quote=maki;127370]Ansonsten bin ich wirklich einverstanden damit selbstgestrickte Standards wie PL/SQL komplett zu ignorieren[/quote]Ja, genau darum gehts:
Die Schicht oberhalb der DB bekommt eine hand voll Prozedurnamen, die sie Aufrufen kann und von der DB Daten geliefert zu bekommen oder diese zu manipulieren. Wie das genau passiert ist Sache der DB. Darum kümmern sich dann Leute, die sich richtig gut mit der gerade gewählten DB auskennen. AFAIK gibt es außer Oracle noch andere DBs, die “Stored Procedures” unterstützen, und nach dem Pattern wären die DBs deutlich einfacher auszutauschen, als wenn ich über ein ORM auf die Daten zugreife, dass womöglich aus Perfomazgründen DB-Spezifische SQLs erzeugt.
Selbstverständlich vereinfacht das nur den technischen Prozess des DB-Wechsels. Wenn ich das wirklich tun wöllte würde ich den Teil der BL, der in der DB liegt neu implementieren lassen müssen. Aber ich wage mal die Behauptung, dass der Aufwand ähnlich dem wäre, wenn der ORM gewechselt würde.
[quote=maki;127370]Oracle war ja auch die Firma die dachte es waere echt toll Java Direkt in der DB laufen zu lassen…[/quote]Das wäre es wahrscheinlich auch gewesen, wenn sie es richtig gemacht, und man die Java-Stored-Procedures nicht über die PL/SQL-API und statische Methoden hätte aufrufen müssen. Und wenn natürlich die JVM in der aktuellen DB nicht immer kurz vorm Supportende gestanden hätte…
[quote=maki;127370]aber sie sind imemr noch wichtig und nicht durch RDBMS zu ersetzen je nach Anwendung[…]manchmal braucht man konsistente Daten, manchmal nicht[/quote]Eben.
Das gilt halt auch umgekehrt.
bye
TT
Stored Procedures sind m.E. nicht standartisiert, aber PL/SQL ist ein viel groesseres Biest, Oracle hat Jahrzehntelang DBAs gezuechtet (und davon haben viele eigenartige Verhaltensweisen)…
Oracle scheint den Umstieg auf die Cloud nicht zu packen soweit ich gesehen habe, alte Bekannte/Freunde die Oracle DBAs sind (und die machen nur Oracle DBA, mit zertifizierung und allem drum und dran, blos kein anderes RDBMS anfassen) machen sich sorgen um ihren Arbeitsplatz.
Naja, von Hibernate nach EclipseLink oder umgekehrt waere fuer mich als Java Entwickler „einfacher“ als DB2 Stored Procedures nach PL/SQL zu migrieren, liegt aber an mir 
Auf der anderen Seite enthaelt das Datenmodell und die Abfragen dazu auch immer Businesslogik IME, d.h. den Split hat man schon.
Frameworks wie JDO/Datanuclues bieten „vollstaendigere“ Abstraktionen an, d.h. komplett eigene Abfragesprache, der Data Store ist komplett austauschbar zwischen RDBMS (verschiedene Hersteller), XML, Key/Value, invertierte Listen, No-SQL usw. usf., deswegen haben Oracle und IBM JDO auch (fast) vollstaendig ausgerottet.