Lookup Table Approach?

Lookup Table Approach?

  

Hi,

Wanted to bounce an "approach" question off of the group...

We typically use a master lookup table approach in our apps to store configuration-type information in a cent5ralized location.

This would include a wide variety of information, including:

* enum values
* Type tables
* Data-driven question options for listboxes
* Configuration settings
* Lists
* etc.

The PKs from this table are used as FKs in other tables (Entities).

We use a centralized facility to avoid an explosion of configuration tables that eventually makes it hard for developers to remember which config or lookup table to use for what purpose, and seems to inevitably lead to repeated config information in different tables.

I'm wondering whether this approach doesn't fit well with an Outsystems app.

What kinds of approaches are folks using to avoid the "config table explosion" problem.

Hi Jeff:

You are correct in saying that that is not best way of doing lookup tables in OutSystems. There are several reasons for that, but the main one is that, by creating one table for each lookup, you are in fact creating a Type for each lookup, as the Table Identifier will become a strong type inside of the platform.

This will avoid a lot of confusion and bugs when assigning ID's since the strong validation of the OutSystems platform will enforce that only ID's of that type can be placed in that field.

For enums, types, static dropdowns and other simple lookups, that do not change in runtime you should use static entities, as they have all the benefits strong typing combined with the database queries inclusion and the values will never be hardwired in the code. For the ones that change in runtime just create a simple list/edit screen and place them in the Enterprise Manager interface.

As for configuration tables I recommend you use site properties whenever the values can only be altered by operations in Service Center and the Enterprise Manager Global Settings table and API.

Feel free to contact me if you require further clarification.

Cheers:

         Miguel