DDS --> SQL

[loeweadolf]

Wenn jemand seine Anwendungen (RPG) nicht grundlegend überarbeiten will, dann kann ich aus den Antworten auf meine Fragestellung (DDS/SQL) keinen Grund erkennen, warum die Tabellen von DDS auf SQL umgestellt werden solten.

Auch ohne Umstellung können DDS-Dateien ja auch bei Bedarf mit SQL bearbeitet werden.

[BenderD]

... ich fühle mich da durchaus richtig interpretiert. Ich würde aber vehement empfehlen alles, was man neu macht, nach neuem Standard zu entwickeln. Sprich: weg von RLA und DDS zu SQL. Sobald man sich in der neuen Denke heimisch fühlt, wird man auch einiges, was man ändert umstellen und alles was Läuft, das läuft: never run a achanging system.

D*B

Wenn jemand seine Anwendungen (RPG) nicht grundlegend überarbeiten will, dann kann ich aus den Antworten auf meine Fragestellung (DDS/SQL) keinen Grund erkennen, warum die Tabellen von DDS auf SQL umgestellt werden solten.

Auch ohne Umstellung können DDS-Dateien ja auch bei Bedarf mit SQL bearbeitet werden.

[RobertPic]

BenderD

genau dieser Einzelzugriff ist aber nicht SQL like, der gehört per Join (besser noch per View) in einen Join im Cursor rein.

Ja das ist schon klar wie man das mit SQL macht. Ist eigentlich noch ein Grund gegen eine Umstellung. Für die optimale Performance genügt es nicht einfach die Dateioperationen 1:1 umzusetzen, sondern mehrere READ's per Join zusammenzufassen.

Fuerchau

und einen SELECT INTO verwenden, und der ist auch nicht langsamer als ein CHAIN/READ INVALID.

Mein Eindruck wahr eher "gefühlt" als gemeesen (drum auch mMn). Die n+1 Problematik dürfte wohl eher bei JDBC/ODBC (wg. Netzerkoverhead) zum Problem werden.

Was noch bleibt, ist, dass bei SQL die Felder noch gemappt werden müssen. Zumindest in Cobol gibt es kein Mapping, da wird der ganze Record verschoben (auch wenn's Müll ist).

@loeweadolf
Ein paar Vorteile (Datei ändern ohne Levelcheck, gleiche Indexe für RPG und SQL) gibt es schon - aber keiner rechtfertigt (für sich alleine) eine Umstellung.

/Robert