-
Ergänzend dazu:
XML und JSON sind Schnittstellendokumente die eben auch mit vielen Methoden erstellt/verarbeitet werden können.
SQL ist da eine der Schlechtesten, da SQL relational ist und XML/JSON hierarchisch.
Die Verarbeitung von XML/JSON ist in anderen, objekt basierenden, Sprachen erheblich einfacher, da ich das Dokument nicht relationalisieren muss.
Sowohl zum Lesen als auch zum Erstellen gibts da halt bessere Methoden.
Die regen Beispiele, auch aus SQL-Server, lassen sich im Code erheblich einfacher verwenden und sind da auch erheblich schneller zu erstellen.
SQL muss da rege Klimmzüge machen um Beziehungen zwischen den Hierarchien mittels Join herzustellen. Im Objektmodell habe ich da Direktzugriffe drauf.
Aber warum ein Programm schreiben, wenn SQL es doch auch kann.
Das sagen dann die, die eher SQL als programmieren können oder noch nicht die richtige Sprache beherrschen;-).
Das ist meine ganz persönliche Sicht, Erfahrung und Meinung.
-
@Baldur,
meines Erachtens geht die ganze Sache noch viel weiter, vor allem wenn Dokumente in's Spiel kommen. Hier finde ich eine relationale DB völlig ungeeignet. Wer sich mal mit MongoDB beschäftigt hat, weiss was ich meine. Und ja, ich bin Fan von dieser DB, weil dagegen die SQL Datenbanken ziemlich alt aussehen.
kf
-
 Zitat von camouflage
@Baldur,
meines Erachtens geht die ganze Sache noch viel weiter, vor allem wenn Dokumente in's Spiel kommen. Hier finde ich eine relationale DB völlig ungeeignet. Wer sich mal mit MongoDB beschäftigt hat, weiss was ich meine. Und ja, ich bin Fan von dieser DB, weil dagegen die SQL Datenbanken ziemlich alt aussehen.
... am Thema vorbei, setzen 5!
... ich nehme mal meinen eigenen Raunzer zurück, sorry Karl.
Im Grunde genommen ist das ein gutes Beispiel für Schichtentrennung und was in die Datenbank an Logik gehört und was nicht.
Dokumente sind hierarchisch geordnete Daten, deren Struktur nicht uniform festgelegt ist (wie in relationalen Datenbanken). Bei sauberer Schichtentrennung, habe ich in der Applikationsschicht ein Objekt (in prozedural gedacht und in ILE formuliert ein Serviceprogramm), das so ein Dokument oder eine Klasse von Dokumenten repräsentiert.
Jetzt brauche ich Methoden (in ILE gedacht exportierte procedures), die eine Dokument aus der Datenbank laden, bzw. in der Datenbank speichern können. Dazu benutzt sie Methoden aus der Zugriffsschicht die rein funktional oder in der Datenbank gespeichert (stored procedures/ user defined functions) sein können.
Mit dieser Architektur ist es völlig egal, ob die Datenbank relational, mongo oder monkey heißt.
D*B
-
 Zitat von BenderD
... am Thema vorbei, setzen 5!
Alles Ansichtssache lieber Dieter.
Wenn schon Best Practices verlangt werden, ist nebst Python, Java oder JSON die Frage nach der DB und deren Handling legitim. Ist halt meine Meinung.
Kann dir auch ein gutes Handbuch dazu empfehlen oder belege mal einen Kurs (learn.mongodb.com, ist free) bei denen - hat noch nie geschadet.
kf
-
Nun, SQL (Structured Query Language) ist also im Wesentlichen eine Abfragesprache, was sie eben sehr effektiv auch kann.
Insert/Update/Delete hat sich da nicht wesentlich geändert, denn die Where-Klausel ist ja wieder ein Query.
Die Prozedursprache von SQL ist sehr dialektlastig, also DB-spezifisch, und reicht im entferntesten nicht an die Möglichkeiten einer Programmiersprache. Beim SQL-Server wird z.B. davon abgeraten größere Prozeduren zu schreiben, da diese die DB insgesamt belasten.
Bei der DB2 for i ist das auch nicht viel anders. Da werden C-Programme erzeugt, die von SQL-Engine aufgerufen wird.
Da ist es doch sinnvoller, das Programm direkt selber zu schreiben und statt SQL eben Prozedur-Aufrufe zu tätigen. Das ist wartbarer und zudem noch effektiver.
Die Implementation von "pSQL" ist sehr verschieden und die wenigsten machen da tatsächlich ausführbaren Code sonderen i.W. interpretierenden Code, also eine Zwischenschicht.
Dazu kommt dann, dass bei zu langer Ausführungszeit, die von verschiedenen Faktoren abhängt, schon Mal ein SQL-Timeout gemeldet wird. Bei einem Service-Programm ist mir das noch nie passiert.
Prozeduraufrufe aus dem Programm sind mit Einzelfeldern und Strukturen möglich und daher sehr effektiv. Strukturen werden gar nicht unterstützt und Arrays sind eigentlich eine Katastrophe.
Und da ja nun MongoDB bereits angesprochen wurde, dann lest dies hier mal:
https://www.mongodb.com/resources/pr...red-procedures
Zusammengefasst: Stored Procedure wird nicht unterstützt und Stored Functions nicht mehr empfohlen. Die wesentliche und nachvollziehbare Begründung ist, dass der Optimizer da keine Chance hat, Abfragen zu optimieren.
-
 Zitat von camouflage
Alles Ansichtssache lieber Dieter.
Wenn schon Best Practices verlangt werden, ist nebst Python, Java oder JSON die Frage nach der DB und deren Handling legitim. Ist halt meine Meinung.
Kann dir auch ein gutes Handbuch dazu empfehlen oder belege mal einen Kurs (learn.mongodb.com, ist free) bei denen - hat noch nie geschadet.
... vielleicht das falsche Forum erwischt? MongoDB auf AS/400 mit RPG - oder gibt es da Neuigkeiten?
Similar Threads
-
By dibe in forum IBM i Hauptforum
Antworten: 1
Letzter Beitrag: 19-10-17, 09:32
-
By NEWSolutions Redaktion in forum NEWSolutions artikel
Antworten: 0
Letzter Beitrag: 11-08-15, 17:07
-
By Kirsten Steer in forum Archiv NEWSblibs
Antworten: 0
Letzter Beitrag: 22-04-11, 10:49
-
By cassandra in forum IBM i Hauptforum
Antworten: 5
Letzter Beitrag: 30-04-03, 14:39
Berechtigungen
- Neue Themen erstellen: Nein
- Themen beantworten: Nein
- You may not post attachments
- You may not edit your posts
-
Foren-Regeln
|
Erweiterte Foren Suche
Google Foren Suche
Forum & Artikel Update eMail
AS/400 / IBM i
Server Expert Gruppen
Unternehmens IT
|
Kategorien online Artikel
- Big Data, Analytics, BI, MIS
- Cloud, Social Media, Devices
- DMS, Archivierung, Druck
- ERP + Add-ons, Business Software
- Hochverfügbarkeit
- Human Resources, Personal
- IBM Announcements
- IT-Karikaturen
- Leitartikel
- Load`n`go
- Messen, Veranstaltungen
- NEWSolutions Dossiers
- Programmierung
- Security
- Software Development + Change Mgmt.
- Solutions & Provider
- Speicher – Storage
- Strategische Berichte
- Systemmanagement
- Tools, Hot-Tips
Auf dem Laufenden bleiben
|
Bookmarks