AnsweredAssumed Answered

many global fields vs. many global variables

Question asked by Wicktor on Jan 20, 2018
Latest reply on Jan 20, 2018 by Wicktor

Referencing to an other question recently posted

Database structure


I think that the framework of the problem should be quite common for those who work on complex professional solutions: there is a need of having a large number of text content to be used inside layouts, dialog messages, etc, Most of those contents are relatively static since they primary depend on language selected by user, which is basically a static choice for each specific user.


I do not see many options to manage such situations, so the dilemma is:

1) have a 1-record table with many hundreds of global fields.

2) having a separate table with many hundreds of records each related to a global variable


It is clear that both options have good and bad aspects.

Option 1) is clearly not the best for data normalisation, but very handy to manage: each "label" has its own field.

Changing a field name is no problem.

On solution start all the content of those hundreds global fields remain loaded into memory even if each specific layout uses only a few of those


Option 2) is best for data normalisation, but a bit more tricky to manage.

Changing a $$variable name will require to go into each script and layout where the variable is used.

Also same concern as above: on solution start there are hundreds of defined global variable which remain loaded into memory


So, wishing that there are some common guidelines, my questions are:

a) which of the two options produces less impact on stability and performance (stand alone and server) ?

b) is it possible to know which of the two options is generally used by the experts ?


Many thanks,