Editcode in SQL beschriebener Datei ?

[BenderD]

Hallo,

Aussagen wie SQL beschriebene Dateien sind schneller als DDS beschriebene oder DDS beschriebene Dateien sind schneller als SQLbeschriebene sind typische Marketing Aussagen und beide falsch!!! it depends, es gibt solche und solche und hängt auch davon ab, wie ich die Dateien verarbeite und von der Hardware auch.
Meine Erfahrung kann man in folgende Aussagen vergröbern:
- Mix zwischen alter Welt (RLA und DDS) und neuer Welt (alles SQL) ist ungünstig
- neue Welt braucht mehr Computer Ressourcen
- alte Welt braucht mehr menschliche Ressourcen
- im kleinen (z.B.: einzelner read) ist alte Welt schneller
- im großen ist neue Welt im Schnitt schneller
- im Highend (multiprozessor + parallel Database Feature) ist neue Welt schneller

Zu dem Editcode ist schon viel gesagt, der bezieht sich auf PRTF und DSPF und das kann man ja mit einer einzigen Datei mit Ref Feldern weiter nutzen, auch wenn man Dateien mit SQL erstellt.
Was SQL angeht, da kann man das meiste mit SQL Mitteln ebenso machen und zwar in einem View Layer (z.B. Query Nutzer). Bei fast allen Frontends kann man die automatische Umsetzung der numerischen Felder steuern, dazu ist bereits genug gesagt. Die Kundennummer kriegt man mit digits(Kundennummer) im Alfa Format angezeigt, sprich ohne Tausenderpunkte und mit führenden Nullen. In solch einem View Layer kann man dann gleich noch (eigene) Functions einbinden, die Währungsaufbereitung und jeden erdenklichen Schnickschnack können.
Wenn man denn gerade mal an so einem View Layer ist, dann kann man da auch gleich alle Joins (korrekt) abbilden, die Benutzer ansonsten selber (manchmal auch korrekt) machen; damit ist auch das Problem weg, dass man über solche aufbereitete Felder nicht joinen sollte.

mfg

Dieter Bender

Hallo AS400 Fan's
SQL Beschriebene Dateien sollen ja schnelle sein als DDS beschriebene.

Bevor ich mich auf den SQL Pfad begebe ..
Wie kann ich den einen Editcode oder ein Editword an die SQL-Table hängen.
mal brauch ich nullenunterdrückung, mal tausenderpunkt und mal ein minus-vorzeichen. geht das mit SQL ?

Max

[B.Hauser]

Hallo,

Aussagen wie SQL beschriebene Dateien sind schneller als DDS beschriebene oder DDS beschriebene Dateien sind schneller als SQLbeschriebene sind typische Marketing Aussagen und beide falsch!!!

hier scheint es mal wieder jede Menge Zweifel und Spekulationen zu geben!

Nur soviel sei gesagt, es gibt architektonische Unterschiede zwischen DDS beschriebenen physischen Dateien und SQL-beschriebenen Tabellen, die bewirken, dass der Lese-Vorgang aus SQL beschriebenen Tabellen schneller ist, als das Lesen aus DDS beschriebenen Tabellen.

Wer's nicht glaubt, liest sich am besten mal den folgenden Artikel durch und probiert's anschließend aus!

Modernizing Database Access
The Madness Behind the Methods
By Dan Cruikshank

Birgitta

[BenderD]

Hallo,

hier geht es nicht um Zweifel oder Spekulationen, sondern um Fakten und deine Argumentation im vorherigen Posting widerlegt dein letztes Posting selber:

Der Grund liegt dafür, dass in DDS beschriebenen Dateien beim Lesen von Daten eine Prüfung der gepackten numerischen Werte erfolgt, während beim Schreiben keinerlei Datenvalidierung erfolgt. Bei SQL beschriebenen Dateien ist dies umgekehrt, d.h. beim Schreiben erfolgt die Prüfung, nicht jedoch beim Lesen.

was ja heißt, dass SQL beim schreiben im Nachteil ist - sprich: der Mix entscheidet.
ich erlaube mir noch zu ergänzen, dass vor dem lesen noch der Query Optimizer zuschlägt, dass Access Pathes berechnet werden, mal besser mal schlechter, sodass der von dir reklamierte Vorteil sich auch wieder verkrümeln könnte.

Eine der typischen Eigenschaften von Marketiers ist, dass sie technische Aussagen vergröbern und verzerren bis es ihnen in den Kram passt.

Dieter Bender,

der manchmal nicht versteht, wer sich wann welche Schuhe anzieht

Hallo,


hier scheint es mal wieder jede Menge Zweifel und Spekulationen zu geben!

Nur soviel sei gesagt, es gibt architektonische Unterschiede zwischen DDS beschriebenen physischen Dateien und SQL-beschriebenen Tabellen, die bewirken, dass der Lese-Vorgang aus SQL beschriebenen Tabellen schneller ist, als das Lesen aus DDS beschriebenen Tabellen.

Wer's nicht glaubt, liest sich am besten mal den folgenden Artikel durch und probiert's anschließend aus!

Modernizing Database Access
The Madness Behind the Methods
By Dan Cruikshank

Birgitta

[Sven Schneider]

Und wenn es nur um Reports geht, hast du mit :

- Query/400 (WRKQRY)
- QM/Query (STRQM)

alle Möglichkeiten der Formatierung, unabhängig was du in der DDS/DDL definiert hast.

Die erstellten Reports kannst du dann auch einem Anwender an die Hand, geben im Gegensatz zu STRSQL.

[Fuerchau]

Stimmt, WRKQRY/STRQM interessieren sich nämlich überhaupt nicht für diese Editcodes.

[Sven Schneider]

Stimmt, WRKQRY/STRQM interessieren sich nämlich überhaupt nicht für diese Editcodes.

Die Editcodes werden bei Query/400 schon als Vorgabe verwendet, ich kann sie aber nach belieben ändern.

QM/Query, da SQL basiert, benutzt die Vorgaben nicht.
Ich kann aber mit Berichtsformularen genau diese Formatierungen (pro Feld) hinzufügen.
Bedingt durch die andere Technik sind die Formatierungmöglichkeiten bei Query/400 und QM/Query leicht unterschiedlich, dürfte aber trotzdem die meisten Anwendungsfälle abdecken. (QM/Query unterstützt keine Editierschablonen, die Datumsformatierung ist auch etwas anders)

[Fuerchau]

QM/Query kann auch kein Vorzeichen rechts des Wertes, es erlaubt ausschließlich amerikanische Editierungen (ausser Dezimalkomma, das aus dem Jobwert kommt).

[alfredo]

Hallo!

Noch ein paar ketzerische Gedanken.

a) Wir haben vor ca. 2 Jahrenauf Grund von Aussagen eines gewissen P.L., mit SQL erstellte Dateien seien x mal performanter uns die Mühe gemacht, das zu checken und konnten keinen signifikanten Unterschied entdecken.

b) Für die Wartung/Dokumentation sind mir die DDS-Sourcen mit Kommentaren/Wartungshistorie ehrlichgesagt lieber.

c) Obwohl es immer geleugnet wird, habe ich gute Erfahrungen mit gezielter Verwendung von LF und SQL bei Joins gemacht.