-
Zitat von Andreas_Prouza
Hab ich denn irgendwo erwähnt, dass man keine View verwenden kann ;-)
Ich bezog mich auf den Zugriff auf die Tabelle. Unabhängig ob jetzt vom Programm oder einer View aus.
... lies doch dein eigenes Statement noch mal, (verwende ich kein select *)
-
Zitat von BenderD
... lies doch dein eigenes Statement noch mal, (verwende ich kein select *)
ja, steht da irgendwo geschrieben: Aber bitte keine View?!
Deshalb hab ich bei meinem vorherigen Post extra erklärt, dass ich mich auf die Zugriffe auf die Physische bezogen habe. Da bei der zuvor geführten Diskussion man herauslesen könnte, dass ein SELECT * auf eine Tabelle keinen negativen Einfluss auf die Performance haben soll.
Ich hoffe damit mich auch für dich verständlich ausgedrückt zu haben, dass es mir hier auf den endgültigen Zugriff auf die Tabelle geht und nicht von wo aus dieser Zugriff kommt.
-
Wie gesagt: lokal ist die Anzahl Felder einer Tabelle für den physischen Zugriff auf dieselbe nicht relavant.
Von der Platte wird ein Block in den FileControlBlock (FCB) gelesen, in dem der komplette Satz in aller Schönheit steht. Nun bedarf es nur noch der Moves aus dem Block in die einzelnen Felder, wobei hier SQL erst mal eigene Felder generiert und im RPGCode noch mal in die Variablen übertragen wird.
Ob man nun 1 Feld oder die max. möglichen 8000 Felder einer PF bewegt liegt unterhalb von Nanosekunden. Die Plattenzugriffe sind da viel entscheidender bevor die Übergabe an das Programm passiert.
Ein FCB kann mehr als 1 Zeile enthalten, so dass der nächste Read nur den Pointer verschiebt.
-
Wenn du z.B. folgendes SQL hast:
SELECT STADT FROM CITY WHERE PLZ = 2000
Und es gibt einen Index mit den Key-Felder PLZ und STADT, dann liest die DB lediglich den Index und erspart sich den Weg zur Physischen Tabelle um die restlichen Spalten zu ermitteln.
Das wird als INDEX ACCESS ONLY bezeichnet.
Das spart viel Zeit im Zuge des Zugriffplans.
-
Ja, aber wer nimmt schon mal mehr als ein paar Felder in den Index?
Ich käme nun nicht auf die Idee, wenn ich die Adresse zu einer Kunden-Nr. brauche, auch noch alle Adressfelder in den Key zu packen.
Aber das ist eher alles eine Designfrage.
Der SQL-Server kennt da z.B. einen Clustered-Index und das ist bereits die 1. Satzebene. Den kann es aber nur 1x geben.
Index-Only verwende ich da eher für (not) Exists-Abfragen, denn da werden Datenfelder i.d.R. nicht benötigt. Das ist schneller als ein Inner Join ohne Felder aus dem Join zu verwenden (s.o.).
-
Ja genau, es ist eine Designfrage.
Man braucht nicht immer alle Felder und wenn man bei etwas komplexeren SQLs (JOINS, Subselects, ...), wo im Zugriffsplan nur wegen einer fehlenden Spalte, die DB auf die Tabelle zugreifen muss, da diese im Index nicht vorhanden ist, dann schaut man sich an ob diese eine Spalte nicht in den Index mit hinein genommen werden kann, sodass die DB eben nicht mehr auf die Tabelle zugreifen muss und mit den Informationen aus dem Index weiter arbeiten kann.
Probier es doch einmal aus und schau dir den Zugriffsplan an.
Berücksichtigt man das nicht, schränkt man sich im Bereich Performanceoptimierung ein.
Es gibt ja viele Möglichkeiten mit der man eine Bessere Performance bekommen kann, wie MQTs, EVI, Index mit Where Bedingung, Partitionierung, das SQL selbst umzubauen uvm.
-
Zitat von Andreas_Prouza
Wenn du z.B. folgendes SQL hast:
SELECT STADT FROM CITY WHERE PLZ = 2000
Und es gibt einen Index mit den Key-Felder PLZ und STADT, dann liest die DB lediglich den Index und erspart sich den Weg zur Physischen Tabelle um die restlichen Spalten zu ermitteln.
Das wird als INDEX ACCESS ONLY bezeichnet.
Das spart viel Zeit im Zuge des Zugriffplans.
... schon mal was von Normalisierung gehört?
-
Zitat von BenderD
... schon mal was von Normalisierung gehört?
Wenn das ganze jetzt wieder in die Richtung geht: Wie klopfe ich blöde Sprüche, dann sollte man dafür einen eigenen Spam-Thread erzeugen!
Scheinbar hast du noch nicht mit Firmen zu tun gehabt, wo ein System historisch gewachsen ist und man vor 30 Jahren noch nicht darauf geachtet hat.
Und nebenbei ist die Normalisierung nur ein Teil des großen Ganzen. Das eine ersetzt nicht das andere.
-
Zitat von Andreas_Prouza
Scheinbar hast du noch nicht mit Firmen zu tun gehabt, wo ein System historisch gewachsen ist und man vor 30 Jahren noch nicht darauf geachtet hat.
Und nebenbei ist die Normalisierung nur ein Teil des großen Ganzen. Das eine ersetzt nicht das andere.
... rein von Alter und Berufserfahrung her vermutlich mehr als Du.
D*B
-
Zitat von BenderD
... rein von Alter und Berufserfahrung her vermutlich mehr als Du.
D*B
Dann bestätigt das nur meine erste Annahme.
Ich konzentriere mich dann doch lieber mehr auf jene Posts derer die konstruktiven Wissensaustausch anstreben und werde nicht mehr auf Kommentare eingehen.
-
Da ja nun neue Anwendungen immer seltener für AS/400 gebaut werden und die vorhandenen auch nicht immer mit SQL umgehen, und wenn dann ohne Journalisierung und Transaktonen, muss man halt mit dem alten Design leben.
Was das Lesen von Daten angeht, so hast du mit den Indizes natürlich vollkommen Recht. Je nach Bedarf macht der eine oder andere mehr da kein Problem.
Anders siehts dann mit dem Updatemanagement aus. Je mehr Indizes mit mehr Spalten, desto aufwändiger ist das dann.
Man muss da auch im Sinne der Performance immer beide Seiten betrachten: Lesen und Schreiben.
Und eins kann ich dir versichern:
Dieter und mir erzählst du da nichts neues;-), ich mache das bei der AS/400 schon seit 29 Jahren und Dieter ist noch ein wenig älter und macht das mit der AS/400 per se schon länger als ich.
Aber wie das nun mal mit uns alten Käutzen so ist...
-
Zitat von Fuerchau
Da ja nun neue Anwendungen immer seltener für AS/400 gebaut werden und die vorhandenen auch nicht immer mit SQL umgehen, und wenn dann ohne Journalisierung und Transaktonen, muss man halt mit dem alten Design leben.
... das zweite ist doch eine der Ursachen für das erste. Und den angehäuften Müll als historisch gewachsen zu beschönigen trägt doch zur Vertiefung des Problems bei. Daten Normalisierung, Entkoppelung von Datenhaltung und Anwendung, Modularisierung, Einsatz von Opensource Komponenten, daran krittelt doch keiner außerhalb des AS/400 Ghettos mehr rum.
D*B
Similar Threads
-
By dschroeder in forum NEWSboard Programmierung
Antworten: 16
Letzter Beitrag: 20-10-14, 14:16
-
By hartmuth in forum NEWSboard Programmierung
Antworten: 3
Letzter Beitrag: 18-09-14, 09:57
-
By Rhenania Computer in forum NEWSboard Server Software
Antworten: 0
Letzter Beitrag: 25-06-14, 10:21
-
By malzusrex in forum IBM i Hauptforum
Antworten: 8
Letzter Beitrag: 06-06-14, 12:44
-
By KB in forum IBM i Hauptforum
Antworten: 1
Letzter Beitrag: 07-09-01, 10:56
Berechtigungen
- Neue Themen erstellen: Nein
- Themen beantworten: Nein
- You may not post attachments
- You may not edit your posts
-
Foren-Regeln
|
Erweiterte Foren Suche
Google Foren Suche
Forum & Artikel Update eMail
AS/400 / IBM i
Server Expert Gruppen
Unternehmens IT
|
Kategorien online Artikel
- Big Data, Analytics, BI, MIS
- Cloud, Social Media, Devices
- DMS, Archivierung, Druck
- ERP + Add-ons, Business Software
- Hochverfügbarkeit
- Human Resources, Personal
- IBM Announcements
- IT-Karikaturen
- Leitartikel
- Load`n`go
- Messen, Veranstaltungen
- NEWSolutions Dossiers
- Programmierung
- Security
- Software Development + Change Mgmt.
- Solutions & Provider
- Speicher – Storage
- Strategische Berichte
- Systemmanagement
- Tools, Hot-Tips
Auf dem Laufenden bleiben
|
Bookmarks