View Full Version : AS400 (RPG) oder PC-Netz
Heutzutage wird ja lieber "generell" gearbeitet und dann geschaut, was das Blechle draus macht.
Ich glaube, das trifft es am besten.
Kann man es so sagen: ?
Es gibt Systeme, die akzeptieren "generelle" Entwicklung klaglos und dann gibt es andere Systeme (AS/400), die das nicht tun. Bei diesem anderen System muss halt etwas mehr Gehirnschmalz investiert, d.h. mehr Entwicklungsaufwand getrieben werden, wenn es anständig laufen soll. Es kann vernünftig laufen, keine Frage, aber eben nur mit höherem Aufwand. Da aber die Entwicklungszeit DER Kostenfaktor eines SW-Hauses ist, kann ich mir vorstellen, dass beim Wettlauf der Systeme die AS400 immer mehr ins Hintertreffen gerät, wenn es sich nicht gerade um einen SW-Hersteller handelt, der sich traditionell diesem System verpflichtet fühlt.
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.
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.
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.
andreaspr@aon.at
15-11-10, 10:14
Kann man es so sagen: ?
Es gibt Systeme, die akzeptieren "generelle" Entwicklung klaglos und dann gibt es andere Systeme (AS/400), die das nicht tun. Bei diesem anderen System muss halt etwas mehr Gehirnschmalz investiert, d.h. mehr Entwicklungsaufwand getrieben werden, wenn es anständig laufen soll. Es kann vernünftig laufen, keine Frage, aber eben nur mit höherem Aufwand. Da aber die Entwicklungszeit DER Kostenfaktor eines SW-Hauses ist, kann ich mir vorstellen, dass beim Wettlauf der Systeme die AS400 immer mehr ins Hintertreffen gerät, wenn es sich nicht gerade um einen SW-Hersteller handelt, der sich traditionell diesem System verpflichtet fühlt.
Hallo Herbert,
Mutig, mutig sowas in einem AS/400 Forum zu schreiben ;)
Wenn du diese "generelle" Entwicklung auf ein anderes System installierst und dort gibt es keine Probleme, dann kannst du gerne sowas schreiben, aber ohne irgendwas getestet zu haben und zu behaupten, dass die AS/400 nicht geeignet wäre, finde ich naiv. Tut mir leid, wenn das jetzt etwas hart klingt, aber genau damit fängt die Problematik an. Und damit meine ich auch euren SW-Hersteller.
Außerdem ein kleiner Tip von mir: Wenn man sich mit einem System (zb AS/400) nicht auskennt, am besten eine Schulung nehmen.
Wenn man sich mit einem System (zb AS/400) nicht auskennt, am besten eine Schulung nehmen.
Ich bin seit /34-Zeiten dabei und seit Anfang an immer ein Fan der AS400.
Offenbar sind das aber nicht alle SW-Hersteller, die zwar das System (halbherzig?) unterstützen weil es doch einige Kunden im Einsatz haben, dann aber darauf hinweisen, man solle für diese Lösung lieber eine andere Platform wählen, weil es erst damit richtig Spaß macht. Und dies muss man dem SW-Hersteller erst mal glauben, denn er hat verschiedene Systeme getestet.
AS400.lehrling
15-11-10, 11:37
Nennt mich kleinkariert :p
Aber wenn ich eine AS/400 im Betrieb habe und immer zufrieden damit gewesen bin.
Hätte so ein SW Anbieter keine Chancen bei mir;)
Auf den Spruch "Für unsere SW brauchen Sie eine andere HW damit es Spaß macht"
Würde mir raus Rutschen "es geht mir nicht um Spaß, Wenn Ihre SW nicht Funktioniert suche ich mir einen Anbieter dessen SW Funktioniert"
Gruß AS400.lehrling
Was hindert dich eigentlich die Indizes anzulegen ?
Pro Tabelle 4-5 Indizes ist doch eher der Normalfall. Schaden tuts jedenfalls nicht sondern bringt die Performance.
Der SQL-Server oder MySQL legen doch Indizes meist automatisch an und keinen störts.
Und am besten die neuen Indizes auch an den SW-Hersteller melden, damit der die bei sich auch gleich anlegt. :rolleyes:
SW-Hersteller interessiert das eher selten da die ihre Software meist nur mit wenigen Daten entwickeln. Ein Tablescan über ein paar Hundert Sätze geht auch beim SQL-Server fix.
Langsamer wirds dann eben bei tausenden oder mehr Datensätzen.
Diese Aufgabe wird daher meist an den DB-Admin verwiesen und da gibt die AS/400 ja wohl genug Hinweise.
"Skalierbar?" - "Logisch. Solange Sie nicht mehr als 500 Datensätze in die Datenbank schreiben."
;)