-
Ich sehe es auch differenzierter als die Meisten.
Klar, eine Funktion die z.B. eine Zahl in ein Datum umwandelt, soll keine Commit-Steuerung benötigen.
Ich sehe aber auch kein Problem wenn eine Funktion für mehr verwendet wird.
Wichtig ist nur, dass es entsprechend Definiert wird.
Eine Funktion deren Name "TRANSFER_DATA_2_IFS" heißt, wird hoffentlich in keiner WHERE Bedingung eingebaut.
Funktionen verwende ich, wenn ich lediglich einen Rückgabewerte erwarte und ich diese in SQL Statements verwenden möchte.
Prozeduren verwende ich, wenn ich über die Parameter mehrere Rückgabewerte benötige.
Wenn es aber aus technischer Sicht im IWS einfacher ist SQL Funktionen zu verwenden, warum soll man sich dann ein Beinbruch machen und komplexe Strukturen erschaffen, damit man am ende des Tages einen Heldentod sterben kann.
Wartbarkeit & Sinnhaftigkeit steht über Religion.
-
 Zitat von dschroeder
Wenn meine Funktion "writeBlob" heißt, würde ich im select schon erwarten, dass sie etwas schreibt. Ich bin natürlich vollkommen deiner Meinung, dass die Benamung der Funktionen und Methoden wichtig ist und klar ausdrücken muss, was eine Funktion tut.
Commitment Control haben wir von 30 Jahre nicht mitbedacht. Das fällt uns jetzt bei einigen Aktionen auf die Füße, aber es lässt nicht mehr mit vertretbarem Aufwand verändern.
Ich verstehe, dass du es kritisch siehst, wenn versucht wird, mit SQL zu programmieren. Aber ich habe ja bereits oben geschrieben, wie meine Anforderung ist. Es geht um große Blobs. Alle anderen Lösungen, die wir durchdacht haben (Webservices ohne IWS, stattdessen nativ in RPG implementieren oder andere Programmiersprachen (Python, Java, nodes.js) dazwischen zu legen), haben auch gewichtige Nachteile. Deshalb erscheint uns SQL sinnvoll.
... es gibt immer einen Weg, neue Programme transaktionssicher zu bauen. Noch wichtiger ist es, Krücken neu zu bauen, die einem den Weg noch weiter verbauen.
Ansosnten bin ich bei Andreas: Daten per Parameter zu empfangen und in die Datenbank zu schreiben ist Alltagsgeschäft für SQL Prozeduren.
D*B
PS: Ob ich allerdings strategisch auf die morsche Bohle IWS setzen würde - was machst Du eigentlich, wenn IBM den schlachtet?
-
 Zitat von BenderD
...
PS: Ob ich allerdings strategisch auf die morsche Bohle IWS setzen würde - was machst Du eigentlich, wenn IBM den schlachtet?
Berechtigte Frage.
Zunächst gehe ich davon aus, dass wir das mit etwas Vorlaufzeit mitbekommen werden. Wir hätten dann genug Zeit, eine Schicht (wahrscheinlich in Java) zu bauen (nicht ich, sondern unsere Java-Developer), die das IWS ersetzt. Mit Springboot ist das auch kein Hexenwerk.
Wir hatten auch schon Kontakt mit Andreas (Prouza). Er hatte da Ideen, so eine Schicht auch in Python oder ähnlichen Sprachen zu bauen.
Ich denke, da gibt es mehrere Möglichkeiten.
Similar Threads
-
By hartmuth in forum NEWSboard Programmierung
Antworten: 2
Letzter Beitrag: 24-07-14, 10:52
-
By Bratmaxxe in forum NEWSboard Programmierung
Antworten: 9
Letzter Beitrag: 24-02-11, 08:37
-
By e_sichert in forum IBM i Hauptforum
Antworten: 9
Letzter Beitrag: 09-05-08, 13:25
-
By e_sichert in forum IBM i Hauptforum
Antworten: 3
Letzter Beitrag: 08-05-08, 09:35
-
By Ewald in forum NEWSboard Programmierung
Antworten: 4
Letzter Beitrag: 24-01-07, 14:38
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