AS400 (RPG) oder PC-Netz

[BenderD]

Die Anzahl der Indexe ist schon verdächtig niedrig, selbst bei konsequenter Nutzung von primary keys und referential constraints ist das wenig und jeder fehlende Zugriffspfad wird mit Laufzeit abgestraft (Genau das erkennt man mit dem Database Monitor).

Was die Timestamps angeht, das ist auf der AS/400 sicher kein Problem, Varchar eher auch nur nachrangig.

D*B

Hier noch einige Daten zu der Anwendung:
1265 Tabellen
883 Indizes vorgesehen
2474 Indizes vom Advisor vorgeschlagen (vor 1 Woche zurückgesetzt)
2056 Triggerprogramme

Jedes Datumsfeld als langen Zeitstempel defniert. Scheint auch so eine "generelle" Entwicklung zu sein. Wäre mir im Traum nicht eingefallen.
Was soll die Millisekunde beim Eintrittsdatum?
Jedes alphanum. Feld, auch unzählige 1-stellige Kennzeichen, mit VARCHAR definiert hatte ich schon erwähnt. Diese Felder wie Mandant oder Lohnart sind Teil von jedem Index. Bei einem langen Textfeld leuchtet mir ja noch ein, dass man damit Platz sparen kann. Aber hier wird kein Platz gespart, im Gegenteil.

[Fuerchau]

Ich kann mir auch nicht vorstellen, dass diese Art der Programmierung bei einem SQL-Server unkritisch sein soll.

Und was die "schnelle" Entwicklung angeht, so unterstützt doch gerade .NET die automatische Generierung von Typed-Datasets, Command's, DataAdapter usw. die dann gerade mit parametrierten Command's arbeitet.
Die Entwicklungszeit reduziert sich damit z.T. drastisch, weil mir .NET erheblich Arbeit abnimmt.
Dies ist dann auch meist so datenbankneutral, dass der simple Austausch der Connection dann mit jedem System funktioniert.

Ausserdem führst du hier Trigger auf. Auch diese können "schlecht" und damit unperformant realisiert sein und zur Bremse werden.

Wie gesagt, eine "schnelle" Programmierung setzt sowieso den Einsatz einer toolgestützten Entwicklung voraus um
a) schneller fertig zu werden
b) performante SQL's zu erstellen
c) Dokumentation zu automatisieren
d) ... und viele weitere Gründe

Ein Quick-und-Dirty zusammengeschusterter SQL ist nie eine langfristig performante Angelegenheit.

Ggf. untersuche mal die Sperren eines QZDASOINIT-Job's und suche nach der Art *SQLPKG (meist in der QGPL angelegt).
Per PRTSQLINF kannst du dir dann die SQL-Befehle und die gespeicherten Zugriffspfade ansehen.

Anmerkung:
Häufig wird auch vergessen, den .NET-DataReader nach EOF (Fill-Methode) zu schliessen und zu disposen, was dazu führt, dass bei wiederholtem Ausführen des Commands mit einem neuen DataReader auch die Datei (ODP, Cursor) nicht wiederverwendet werden kann (der Cursor ist ja noch offen).
Auch dies führt zu nicht unerheblichen Performanceverlusten.