[NEWSboard IBMi Forum]
Seite 2 von 4 Erste 1 2 3 ... Letzte
  1. #13
    Registriert seit
    Nov 2020
    Beiträge
    315
    Genau, oder so wie Robert geschrieben hat, wenn die Ziel-DS hardcoded erstellt wurde, die Tabelle geändert und dann das Programm neu kompiliert wurde.
    Dann sind die neuen Spalten der Tabelle im Zugriff, aber noch die alte Datenstruktur, wenn diese nicht ebenfalls mit angepasst wurde.

  2. #14
    Registriert seit
    Feb 2001
    Beiträge
    20.207
    Das würde beim Compile bereits auffallen und wer schreibt die DS noch selber, wenn ich einen Bezug zur Datei machen kann?
    Dienstleistungen? Die gibt es hier: http://www.fuerchau.de
    Das Excel-AddIn: https://www.ftsolutions.de/index.php/downloads
    BI? Da war doch noch was: http://www.ftsolutions.de

  3. #15
    Registriert seit
    Mar 2002
    Beiträge
    5.286
    ... alle diejenigen, die vom select * abraten und das sind ja nicht wenige "Experten"!
    AS400 Freeware
    http://www.bender-dv.de
    Mit embedded SQL in RPG auf Datenbanken von ADABAS bis XBASE zugreifen
    http://sourceforge.net/projects/appserver4rpg/

  4. #16
    Registriert seit
    Aug 2001
    Beiträge
    2.869
    Zitat Zitat von Fuerchau Beitrag anzeigen
    Das würde beim Compile bereits auffallen und wer schreibt die DS noch selber, wenn ich einen Bezug zur Datei machen kann?
    Nicht zwangsläufig! Solange die Spalten-Definitionen (in der Reihenfolge) übereinstimmen bzw. compatibel sind und lediglich weniger Ausgabe-Felder vorhanden sind als ausgewählt, wird das Programm erstellt.

    SQL0030 (Anzahl der Host-Variablen geringer als die Ergebnis) hat Severity 0 und verursacht somit keinen Fehler.
    Im (RPG) Programm selber wird lediglich eine Warnung mit SQLCODE +30 ausgegeben. Die Daten werden jedoch korrekt ausgegeben.
    ... das einzige ist, die störende Meldung
    und ggf. tatsächlich eine Beendigung der Verarbeitungsschleife, weil der Programmierer mal wieder (entgegen aller Empfehlungen) auf SQLCODE = 0 oder SQLSTATE = 00000 prüft.

    Im Übrigen kommen solche "Fehler" auch häufig vor, wenn 2 Tabellen verjoint werden und alle Felder mit SELECT * ausgewählt werden und der Programmierer sich entscheidet, dass nur die Daten der ersten Datei benötigt werden und im Fetch nur die Datenstruktur der ersten Datei angegeben wurde.

    SELECT * sollte man m.E. grundsätzlich vermeiden und immer nur genau die Spalten auswählen die man auch wirklich benötigt, auch wenn man wie Dieter für jede Abfrage eine View baut.
    Vielleicht braucht man die gleiche View doch mehrfach und möchte dann irgendwann Spalten hinzufügen ...

    Birgitta
    Birgitta Hauser

    Anwendungsmodernisierung, Beratung, Schulungen, Programmierung im Bereich RPG, SQL und Datenbank
    IBM Champion seit 2020 - 4. Jahr in Folge
    Birgitta Hauser - Modernization - Education - Consulting on IBM i

  5. #17
    Registriert seit
    Mar 2002
    Beiträge
    5.286
    Zitat Zitat von B.Hauser Beitrag anzeigen
    SELECT * sollte man m.E. grundsätzlich vermeiden und immer nur genau die Spalten auswählen die man auch wirklich benötigt
    Birgitta
    ... das hat erhebliche Folgerungen:
    - erhöhter Programmieraufwand
    - man kann keine externen Datenstrukturen verwenden
    - Fehler in der Feldreihenfolge führen zu tückischen Fehlern
    - Redesign Schritte an der Datenbank sind aufwändig und fehlerträchtig
    - massive Performance Einbrüche bei remote Zugriffen mit dynamischem SQL

    D*B
    AS400 Freeware
    http://www.bender-dv.de
    Mit embedded SQL in RPG auf Datenbanken von ADABAS bis XBASE zugreifen
    http://sourceforge.net/projects/appserver4rpg/

  6. #18
    Registriert seit
    Apr 2005
    Beiträge
    385
    ... das hat erhebliche Folgerungen:
    - erhöhter Programmieraufwand
    - man kann keine externen Datenstrukturen verwenden
    - Fehler in der Feldreihenfolge führen zu tückischen Fehlern
    - Redesign Schritte an der Datenbank sind aufwändig und fehlerträchtig
    - massive Performance Einbrüche bei remote Zugriffen mit dynamischem SQL
    Da kann ich Dieter nur Recht geben! Brauche ich nur 1-3 Felder einer Datei, dann mache ich eine ZielDS oder gezielt in Host-Variablen.

    Brauche ich aber >5 Felder einer Tabelle, dann mache ich Select * mit einer E DS.

    Und RPG ist da nicht die einzige Sprache die eine solche Funktionalität zur Verfügung stellt. Auch in ABAP kann das so gemacht werden.

  7. #19
    Registriert seit
    Feb 2001
    Beiträge
    20.207
    Tja, da zeigt sich mal wie immer: Man muss wissen was man tut;-).
    Einen Performanceunterschied zwischen Select * und Select f1, f2 ... konnte ich bisher nicht feststellen.
    Der interne DB-Read liest sowieso den ganzen Satz und die SQL-Runtime macht dann nur noch ein paar Moves. Bei sinnvoller Verwendung von "DataPointern" (Zeiger auf Daten mit Feldspezifikation) werden die das wohl sinnvoll implementiert haben. Auch im RPG findet man dann nur Moves.
    Und Millionen von Moves sind immer noch schneller als 1000de von Read's.

    Anders siehts tatsächlich bei remoten DB's aus, da ich gezielt durch Angabe der Felder weniger Daten übertragen muss.

    Und was den Join-Quatsch angeht.
    Selbst da könnte ich einen "Select a.* from a inner join b on ..." durchaus machen, wobei da ein "where exists " durchaus sinnvoller ist.
    Dienstleistungen? Die gibt es hier: http://www.fuerchau.de
    Das Excel-AddIn: https://www.ftsolutions.de/index.php/downloads
    BI? Da war doch noch was: http://www.ftsolutions.de

  8. #20
    Registriert seit
    Mar 2002
    Beiträge
    5.286
    Zitat Zitat von Fuerchau Beitrag anzeigen
    Tja, da zeigt sich mal wie immer: Man muss wissen was man tut;-).
    Einen Performanceunterschied zwischen Select * und Select f1, f2 ... konnte ich bisher nicht feststellen.
    Der interne DB-Read liest sowieso den ganzen Satz und die SQL-Runtime macht dann nur noch ein paar Moves. Bei sinnvoller Verwendung von "DataPointern" (Zeiger auf Daten mit Feldspezifikation) werden die das wohl sinnvoll implementiert haben. Auch im RPG findet man dann nur Moves.
    Und Millionen von Moves sind immer noch schneller als 1000de von Read's.

    Anders siehts tatsächlich bei remoten DB's aus, da ich gezielt durch Angabe der Felder weniger Daten übertragen muss.

    Und was den Join-Quatsch angeht.
    Selbst da könnte ich einen "Select a.* from a inner join b on ..." durchaus machen, wobei da ein "where exists " durchaus sinnvoller ist.
    ... bei remote Verarbeitung werden niciht nur Daten, sondern auch die Statements übertragen!!!
    Ich erinnere mich da an einen Kunden, der von "Experten" beraten wurde und denen man eine "Modernisierung" verkauft hat. Da wurden alle Quellen mit Tools nach total free RPG konvertiert, anschließend hat man sich nicht getraut das auch zu wandeln und in Produktion zu setzen und festgelegt das bis zur jeweils nächsten Änderung eines Programms zu verschieben. Dann hat man alle DDS erstellten Dateien nach SQL beschriebenen umgesetzt und dabei Autoincrement keys, und Timestamps für Anlage und Änderung zugefügt, sowie alle Feldnamen sprechend gemacht und gravierend verlängert. Da alle Programme mit RLA zugreifen, hat man anschließend die alten DDS LFs wieder draufgesetzt und alle Keybeziehungen, wie vorher wieder hergestellt.
    Anschließend wollte man die Datenbank dann auf einen MS SQL-Server verschieben. Select * war dabei genauso verboten, wie die Erstellung "unnötiger" Views. Im proof of concept zeigte sich dann, das die Übertragung der überlangen SQL Statements mehr ausbremste, als eventuell unnötige Felder.

    Gegen das Weglassen nicht benötigter Felder ist nichts einzuwenden (oft sind in Dateien mehr nie sinnvoll gefüllter Felder als tatsächlich benutzter), dann aber per View mit Select * und externen Datenstrukturen.

    D*B
    AS400 Freeware
    http://www.bender-dv.de
    Mit embedded SQL in RPG auf Datenbanken von ADABAS bis XBASE zugreifen
    http://sourceforge.net/projects/appserver4rpg/

  9. #21
    Registriert seit
    Feb 2001
    Beiträge
    20.207
    Wenn man wiederholbare SQL's mit Parametermarkern ausführt, gerade bei Update/Inserts werden nur noch Daten statt Statements übertragen.
    Aktuelle bin ich gerade bei einer ETL-Optimierung.
    Da wird aus einer AS/400-DB mit 240Mio. Zeilen eine Select mit Ergebnis 65Mio Zeilen in einen SQL-Server gschoben. Dies dauert ca. 1 Stunde, macht 18.000 Inserts/Sekunde.
    Da dies zu lange dauert, hat man bei einer "Analyse" festgestellt:
    - Der SQL-Server hat fast nichts zu tun und wartet auf die AS/400
    - Die AS/400-QZDASOINIT-Jobs stehen fast nur auf TIMW, warten also auf Anforderungen vom SQL-Server.

    Ich habe da nun ein C#-Programm gemacht, dass diese 65Mio. Zeilen mit ca. 98.000 Zeilen/Sekunde abholt. Somit wäre ich nach knapp 11 Minuten fertig mit dem Download.

    Antwort von der Microsoft-Truppe:
    Ich weiß nicht was sie da machen und kann das nicht verifizieren. Unsere Seite hat ein Microsoft-Spezialist untersucht und keine Beanstandungen gefunden. Folglich muss es an der Bereitstellung der AS/400 liegen!
    Das ist nun Fakt, also machen Sie die AS/400 schneller.

    Was soll ich denn schneller machen, wenn das ETL-Programm (SSIS) einfach nicht schneller kann?
    Ich bin schon am überlegen, ob man nicht eine CSV auf der AS/400 erstellt (geht ja fix) und dann mit 1GBit auf den Windows-Server schiebt. Dann können die vielleicht einen BulkLoad mit SSIS machen und in Summe wäre das vielleicht noch schneller.

    Denn mit meinem C#.Progrämmchen rufe ich auch den Bulkload auf und konnte auf meinem langsamen Laptop bereits 23.000 Zeilen/Sekunde importieren. Was muss da wohl ein SQL-Server mit BulkLoad schaffen...
    Aber ein SQl-Server zum Beweis wird nicht zur Verfügung gestellt.

    Noch ein Nachsatz: Wir haben das Problem bereits seit 1,5 Jahren und seitens IBM ist keine Verbesserung eingetreten.

    Ich kann da nur sagen: Eindeutig (mal wieder) ein massives Problem vor dem Bildchirm.
    Dienstleistungen? Die gibt es hier: http://www.fuerchau.de
    Das Excel-AddIn: https://www.ftsolutions.de/index.php/downloads
    BI? Da war doch noch was: http://www.ftsolutions.de

  10. #22
    Registriert seit
    Nov 2020
    Beiträge
    315
    Es ist schon richtig: Bei sehr performanceintensiven abfragen, verwende ich auch kein SELECT * sondern wähle wenn möglich nur jene Spalten aus, die benötigt werden.
    Dadurch kann ich mir, mit entsprechenden Index, einen Zugriff auf die Tabelle sparen und er liest nur den Index, da dieser eventuell alle Informationen schon beinhaltet.

    Klar, bei einem 0815 SQL verwende ich auch ein SELECT * mit EXT DS.
    Wenn es aber darum geht zeitkritische Abfragen zu beschleunigen, ist das sehr wohl ein Punkt (von mehreren) der in Betracht gezogen werden muss.

  11. #23
    Registriert seit
    Mar 2002
    Beiträge
    5.286
    Zitat Zitat von Andreas_Prouza Beitrag anzeigen
    Es ist schon richtig: Bei sehr performanceintensiven abfragen, verwende ich auch kein SELECT * sondern wähle wenn möglich nur jene Spalten aus, die benötigt werden.
    Dadurch kann ich mir, mit entsprechenden Index, einen Zugriff auf die Tabelle sparen und er liest nur den Index, da dieser eventuell alle Informationen schon beinhaltet.

    Klar, bei einem 0815 SQL verwende ich auch ein SELECT * mit EXT DS.
    Wenn es aber darum geht zeitkritische Abfragen zu beschleunigen, ist das sehr wohl ein Punkt (von mehreren) der in Betracht gezogen werden muss.
    ... was soll denn bei einem select Feldliste schneller sein als ein Select * auf eine View mit derselben Feldliste?
    AS400 Freeware
    http://www.bender-dv.de
    Mit embedded SQL in RPG auf Datenbanken von ADABAS bis XBASE zugreifen
    http://sourceforge.net/projects/appserver4rpg/

  12. #24
    Registriert seit
    Nov 2020
    Beiträge
    315
    Zitat Zitat von BenderD Beitrag anzeigen
    ... was soll denn bei einem select Feldliste schneller sein als ein Select * auf eine View mit derselben Feldliste?
    Hab ich denn irgendwo erwähnt, dass man keine View verwenden kann ;-)
    Ich bezog mich auf den Zugriff auf die Tabelle. Unabhängig ob jetzt vom Programm oder einer View aus.

Similar Threads

  1. Omnifind, Anzahl der Indexspalten
    By dschroeder in forum NEWSboard Programmierung
    Antworten: 16
    Letzter Beitrag: 20-10-14, 15:16
  2. Anzahl der Host-Variablen geringer als die Ergebniswerte
    By hartmuth in forum NEWSboard Programmierung
    Antworten: 3
    Letzter Beitrag: 18-09-14, 10:57
  3. Gelangensbestätigung: Geringer Arbeitsaufwand für Versender und Empfänger
    By Rhenania Computer in forum NEWSboard Server Software
    Antworten: 0
    Letzter Beitrag: 25-06-14, 11:21
  4. SQL mit Vergleich ANzahl Sätzen pro Kunde
    By malzusrex in forum IBM i Hauptforum
    Antworten: 8
    Letzter Beitrag: 06-06-14, 13:44
  5. Beschränkung auf Anzahl Felder in Tabelle????
    By KB in forum IBM i Hauptforum
    Antworten: 1
    Letzter Beitrag: 07-09-01, 11:56

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • You may not post attachments
  • You may not edit your posts
  •