Umstellung DDS auf DDL, Datum- und Zeitformat macht Probleme

[Fuerchau]

Da muss ich Dieter auch zustimmen. Das Datumformat ist leider ein kritischer KO-Punkt für solche Vorhaben. Und was ist denn tatsächlich damit gewonnen?
Außer der Indexblockung von 64-KB statt 4KB gibt es keinen Unterschied und von der Performance her gibt es auch eher marginale wenn überhaupt messbare Unterschiede. REUSEDLT(*YES) kann man auch schon bei DDS einsetzen.
Da ist es schon gravierender VARLEN-Felder in den Satz zu definieren an Stelle dies dem Zufall zu überlassen, denn im Satzaufbau ändert sich dadurch nichts, aber man spart echte IO's.
Oder bei SQL-Zugriffen vernünftige Indexanalyse oder Statementanalyse zu betreiben.

[dschroeder]

Im Moment sehe ich für uns auch keine Möglichkeit der totalen Umstellung. Zur Zeit fahren wir die Strategie, neue Tabellen mit DDL zu beschreiben. Wir nutzen dann z.B. autogenerated Keys. Unsere Dateizugriffe machen wir seit längerem bei neuen Programmen nur noch per SQL. Bei Programmänderungen werden oft auch alte Programme auf embedded SQL umgestellt. Es ist eben nur so, dass ein Datumsfeld der neuen DDL beschriebenen Tabellen ja vielleicht auch mal an ein "altes" Programm per Referenz übergeben wird. Dann knallt es. Es ist sehr unschön, dass jeder Programmierer jetzt im Hinterkopf haben muss, wie die Tabellenstruktur beschrieben ist (DDS oder DDL). Bisher habe ich nicht gedacht, dass das einen Unterschied macht.

Wir setzen häufig Tools ein, um Datensätze (also extern beschriebene Datenstrukturen) zu lesen und zu schreiben. Durch die Namenskonventionen weiß ich genau, wie ein bestimmtes Tool für eine Datei heißt, bzw. ich kann mir den Toolnamen aus unserem Repository heraussuchen. Die Dateien gucken wir uns oft mit SQL an, oder mit einem Browsertool, das uns die Strukturen auflistet oder wir nutzem einfach die Kontexthilfe mit Rdi (Strg + Space), um die Felder einer Datenstruktur angezeigt zu bekommen. Diese Information reichts jetzt eigentlich nicht mehr. Eigentlich müsste ich immer, wenn ich mit einem Datumsfeld hantiere, konkret in die Dateibeschreibung schauen, um nachzusehen, ob die Datei mit DDS oder mit DDL beschrieben ist.

Das finde ich so unschön.

[Fuerchau]

Wenn du mit SQL umgehst, ist das nicht relevant wie die Datei definiert ist, sondern wie du die Hostvariablen deklarierst. Wenn du allerdings Hostvariablen wiederum als externe DS definierst stehst du vor dem selben Problem.

Das selbe gilt auch für die schönen Prototypen, die ausschließlich zur Compilezeit geprüft werden. Eine Laufzeitprüfung, die ggf. Typsicher wäre, erfolgt nun mal nicht.

Anscheinend erfolgt auch keine Prüfung des Prototyps bei abweichendem Datumformat. Hier erfolgt generell ein ausschließlicher Felddefinitionsvergleich ohne Datumsformat.
Da kann man sich dann gar nicht sicher sein, dass sowas dann gutgeht.

Auch finde ich es (persönlich) seltsam, Schnittstellen auf Basis EUR-Date zu definieren wo man doch schon seit Jahrzehnten weiß, dass nur ein ISO-Date immer und überall kompatibel ist.

Da hilft auch alles Jammern nicht. Du musst halt den schweren Weg der Vorabanalyse gehen und zumindest was die externen (unbeeinflussbaren) Schnittstellen angeht, hier die Prototypen auf CONST umzustellen.

[BenderD]

Zur Zeit fahren wir die Strategie, neue Tabellen mit DDL zu beschreiben. Wir nutzen dann z.B. autogenerated Keys. Unsere Dateizugriffe machen wir seit längerem bei neuen Programmen nur noch per SQL. Bei Programmänderungen werden oft auch alte Programme auf embedded SQL umgestellt.

Bis dahin bin ich ja völlig bei Dir. Was mir fehlt ist:
- neue Funktionen Parameter nur noch per VALUE (oder CONST, falls Programm oder als Implementierung einer externen SQL Function.
- Bei Änderung von Funktionen neue Schnittstelle (VALUE) zufügen.
- bei Änderung von Verwendung in Programmen auf VALUE umhängen.
- bei partiellem Redesign Datenbank: View Layer zur Entkoppelung einziehen
- bei Neuverwendung oder Änderung keine Zugriffe mehr auf das physical Layer.
-- jetzt kann man das physical Layer auf SQL DDL umstellen

Strategie hierbei, alte Welt zurückdrängen, um Freiheitsgrade im Datenbank Redesign durch Entkoppelung zu gewinnen. Wenn für eine Datei/Funktion die alte Welt nur noch marginal gebraucht wird, kann man (muss man aber nicht) rückbauen.

D*B,

der sich alle Probleme, die man nicht haben muss, gerne vom Hals hält!

PS: @Baldur: Datums Parameter per value oder const werden immer passend gemacht - und Übergabe per Reference ist in > 95% aller Fälle ein Kunstfehler.

[dschroeder]

Ich muss zugeben, die Ideen von D*B klingen vernünftig. Ich habe ja bereits gesagt, dass ich die Sache mit dem View Layer bei uns mal anspreche. Die anderen Punkte nehme ich dann auch gleich mit auf.
Der Punkt mit den 95% Kunstfehler bei Referenz ist aus meiner Sicht richtig, wenn man die alten Anwendungen aus heutiger Sicht betrachtet. Vor 20 Jahren hat man aber die meisten Programme als normale Programme (also Nicht-Serviceprogramme) geschrieben (Ich weiß gar nicht, ob damals Serviceprogramme schon gingen). Und da hat man einfach PARM-Anweisungen verwendet. Das war der Standard. Und das sind nun mal Calls per Reference. Ich weiß nicht, ob man damals die Parameter von "normalen" Programmen als const definieren konnte. Ich habe das jedenfalls nirgendwo gesehen.