Static Entities verses Normal Entities with Bootstrap Load from Excel

I was reading some earlier posts where people wanted to minimise the number of SU's for an application, and a few people mentioned the relatively high SU cost of a static entity. There was a suggestion to replace static entities with normal entities, and have their values bootstrapped from an Excel file. I always thought there was something special about static entities over normal entities, I thought the OutSystems model compiler would optimise the performance of static entities, but I can't find any solid proof of that. Does anyone know? My understanding (presumption?) was that if I had an action say that referred to the "label" of a particular static entity instance, it would NOT result in a database lookup being performed, since the compiler knows the result at compile time (since the content of static entities can only be changed by republishing the application, not by direct database updates, unlike normal entities). But also, if a particular query does a "join" against the static entity, that will be executed in SQL because the entity data is also stored in the database - the compiler chooses the most efficient approach depending on the exact situation.

Could anyone confirm that I've understood this right? It's not vital, it's just that I've sometimes used this as an example of the kind of optimisations you get for free with OutSystems and I just wanted to make sure I'm not talking nonsense!
Hi Andrew,

Yes, there are optimizations done to avoid unnecessary queries.

Both "Entities.SomeEntity.Item" is known and "GetSomeEntity (...)" operation uses cached results.
Those are updated if the eSpace that owns the entity is republished.

When used in query joins it still does the queries since it's faster and can be a complex operation depending on the query.

Also a nice advantage of them is that the values can be translated (Note that this needs to be activated in the Entity Advanced properties). Translations are respected automatically even when used in queries.

João Rosado