SETOBJACC hat sich durch die intelligenteren Cachefunktionen längst überholt. Ausßerdem lohnt das nur, wenn man dafür eigene Speicherpools definert, die dem Paging dann nicht unterliegen.

Eas Arrays angeht, so habe ich nicht geagt, dass man alles und jedes cachen muss, da für einen Binärzugriff das Array auch jedesmal neu sortiert werden muss.
Dies lohnt eher für Arbeitsarrays, wenn diese sich sortieren lassen und eine Suche mit "=" erfolgt.
Für andere Suchen gibt es keine Binärsuche.
Allerdings ist dies bei Tabellen bis 100 Elementen auch nahezu unmessbar.

Wie bereits gesagt, SQL ist beim Suchen von Information und dem eingeschränkten Lesen (also nur gefilterte Ergebnisse) meist schneller als native Funktionen. Ins besonders wenn Index-Only-Access zum Tragen kommt. Nicht zu vergessen, VARLEN-Felder immer in ihrer Gesamtheit im Datensatz zu definieren da somit je Feld u.U. kein 2. IO erforderlich ist (Ausnahme LOB's, da gehts ja nicht anders).