Hi edoo,

what you describe is a common pattern / solution to deal with large amounts of code / value pairs (from a database perspective) in any software stack, not necessarily Outsystems.  

There is typically the trade-off between less development and maintenance (such as admin functionality to update available codes only to be developed once) of making one general code/value table, versus better readability of your code and your datamodel when making a code/value entity for each of the types of things you want to codify.

In Outsystems, static entities have more similarity with the second option, as far as datamodelling is concerned, i.e. it is directly clear from your datamodel what the possible values are for a given attribute.  But static entities are much more than that, they offer a way to easily, and human readably, make reference to the possible values in code without hardcoding their value, it allows for findability if you want to know in what parts of your code a given value is explicitly used, etc.  So you shouldn't think of static entities as merely a code value table.

I think also there is a lot of value in showing the real complexity of your system in your datamodel, if you happen to be so lucky as to be allowed to work on a very complex system with dozens of coded attributes that your software has to do interesting stuff with, it is a good thing that this complexity is visible by the complexity of your datamodel picture, don't hide it !

If you are hell bent on sticking everything in a single table, you always have the option of not using static entities at all for this, but just use regular entities (as you would do in other stack, probably)  If you make some smart wrappers / getters, this could be a good solution.

When you want it as statics, then I don't see the advantage of trying to push everything in one table.  Statics don't need any maintaining so where is the downside to having many of them, and you will have to take into consideration what subset of them you want, every single time you use them.  The only thing it would do for you, is declutter your datamodel diagrams, maybe ?  

If I would want to do this with statics, I would codify the name of the static something like type_value, I don't think you need a separate foreign key to a type.  EDIT : I do see the point of having a type, as a means to select all values of a given subset. And I would make dedicated getters retrieving each subset.  But you are still stuck with for example making sure that only foreign keys of the correct type are created.

Bear in mind if making this type of choices, that other people will also work on your software, and having to explain it is a big disadvantage over just using things that everybody already knows and uses, like the 'normal' way of using statics.

One single consideration PRO, maybe statics count as application objects, so can be costly to have many of them.

Dorine

Hi edoo,

see attached oml for an example with static entities.  Game1 is with separate static entities for each property, Game2 has all possible values in a single static entity.

I'm a bit done with this now, so no example for regular entities, but I imagine that would be with the property table still a static, but the property value table a regular one, meaning you can't invent new properties on the fly, but users can easily add new allowed values.  As long as the made choices are stored in an explicit/discrete way (explicit reference attribute in game entity) there is no point in making property configurable in runtime, I think.

Most stuff would probably be similar, for regular entities, except you wouldn't be able to code the example business rule.

So the 2 provisions i added to deal with the fact that the distinction between the types is a bit lost in the datamodel, is extra validation action ValidatePropertyValueIsOfProperty and webblock PropertyDropdown.

This kind of approach is only suitable if the chosen options are not much more than that, a choice from a discrete set of options that you want to record.  As soon as you want to write a lot of business logic with them, or you want to make all kinds of behaviour of your system depend on them, then single statics work better.  You can then for example configure the system behaviour through extra attributes in the relevant static, and if all are in a single static table, that's less possible.

Dorine