Es gibt noch einen wesentlichen Unterschied zwischen LIB und COLLECTION.

Beim CREATE COLLECTION werden automatisch Journale erstellt und alle, per CREATE TABLE erstellt Tabellen in diesem Journal aufgezeichnet.

Für ALTE RPG-Programme ist ein CREATE TABLE sogar tödlich:
1. Satzformatname = Dateiname (umbenennen in RPG erforderlich)
2. Neue LVLCHK-ID !

In einer SQL-Datensammlung sind ausschließlich TABLE, INDEX und VIEW erlaubt (neben FUNCTION, PROCEDURE, usw.).
Da eine SELECT-LF nicht SQL-spezifisch ist, wird dieses abgelehnt.

Ausserdem kann ein RPG zwar auf eine VIEW zugreifen, allerdings nur rein sequentiell.
Eine VIEW hat keine KEYS und damit ist SETLL/SETGT/READE nicht mehr möglich.

Nun zu SQL:
Greifst du per SQL auf eine VIEW zu, ist dies eigentlich ein vordefinierter SQL der nicht weiter mit WHERE eingeschränkt werden sollte (also nur SELECT * FROM VIEW [order by ...]).
Solltest du etwas anderes tun, kann SQL die View gar nicht verwenden sondern ergänzt deinen SQL nur mit den zusätzlichen WHERE bzw. GROUP BY und fängt die Analyse über die PF wieder von vorne an.

Auch wenn du per SQL auf eine LF-View (mit Select/Omit) zugreifst, wird dein SQL angepasst und über die PF und Indizees neu analysiert.

Wenn du deine PHP-Zugriffe optimieren willst musst du entsprechende Einträge in die QAQQINI bzgl. Diagnose-Nachrichten machen und dann den Hinweisen des Joblogs folgen. Bei mir hilfts in 95% aller Fälle.
Den Rest kann man dann per STRDBMON analysieren was etwas aufwändiger ist.

Ach ja:
Es gibt immer noch einen Unterschied bzgl. des Optimizers (alt/neu).
Wenn eine LF mit SELECT vorhanden ist, wird der ALTE Optimizer aufgerufen, ansonsten der neue.
Auch dies kann Performance-Nachteile mit sich bringen.