Just to make sure that there is no misunderstanding I meant RAM restrictions on the single object-level and not in regard to the server.
I don't know how direct query tables are loaded and associated with the datamodel but I have some doubts that they are loaded like normal Qlik data (each field with only distinct values within an own system-table which is linked with a bit-stuffed pointer to the real data-tables) because it would in general require to refresh those system-tables and the pointers. Therefore I assume they are more or less loaded like they are in sql within an additionally layer in the datamodel.
This may cause a significantly increase of the RAM consumption while creating the virtual table which is underneath your visible table in the UI. Virtual table means to combine all required dimensional information on which then the applied measures are performed (they need always a dimensional context). Such virtual tables could be several orders of magnitude bigger as the visible one in the UI. Especially if the dimensions/expressions use nested if-loops, aggr-constructs and/or interrecord-functions it will require a lot of resources particularly if the included fields didn't come from one table else multiple ones and in the worst case associated through link-tables.
AFAIK direct query is aimed to pull small datasets like a few real-time currencies or similar stuff into an application but not to pull large fact-tables which will take often too much time - the response times from the queried database + network is usually much higher as just keeping these data already within the normal loaded datamodel. Therefore this would be my first suggestion - just load them normal.
- Marcus
