How many records can we create in static entity? Is it a good practice to create thousands of record in static entity? If not, please explain the reason why?

Thanks in advance

Lovish Goyal wrote:

How many records can we create in static entity? Is it a good practice to create thousands of record in static entity? If not, please explain the reason why?

Thanks in advance

Why would you want thousands of records in there?

Hi, Lovish

Records in Static Entities work as identifiers, and I believe you will be able to create as many as you would identifiers in an Entity. The practical use of Static Entities is to have data with a global scope completing your application with the content you defined.

Regards,

Sam

I've seen this crop up in some projects where you need a large set of mostly fixed data (think a list of Countries, for example).

It's not very practical to create so many records in a Static Entity because you'll have to manage them individually by hand - even if you bootstrap them any changes/deletes afterwards will be troublesome. Static records are used to save time and clarify code by letting you refer to a value by a recognisable shorthand - whatever ease of use you gain is lost when you have thousands.

At that point I'd just create a normal Entity to store my values - easier to manage, even if the resulting code is a little harder to read.

I totally agree with Afonso, having Static Entities with so many records is useless, and certainly nog good practice! The main use for Static Entities are 1) for the developer, being able to use a (hopefully) meaningful identifier instead of some magic hardcoded value, and 2) for the user, being able to select a value from a combo box. In both cases the number of records should be limited for any practical use.

Afonso Carvalho wrote:

I've seen this crop up in some projects where you need a large set of mostly fixed data (think a list of Countries, for example).

It's not very practical to create so many records in a Static Entity because you'll have to manage them individually by hand - even if you bootstrap them any changes/deletes afterwards will be troublesome. Static records are used to save time and clarify code by letting you refer to a value by a recognisable shorthand - whatever ease of use you gain is lost when you have thousands.

At that point I'd just create a normal Entity to store my values - easier to manage, even if the resulting code is a little harder to read.

You are right Afonso. In our current project we are using static entity to validate the different sections of the application. Everytime a component is built we have to create its section. So huge records are already created and now we have to compromise with our logic part i.e. we have to create our logic in such a way that a few records needs to be created for static entity. By doing this we are losing its generic feature. That's why i have asked, how many records we can create? Is there extra load on db to fetch records from static entity? I want to understand its consequences. Because what i think that they are bydefault indexed due to its retival operation only. So it shouldn't create any problems to create as many records.

 


I don't think there's a hard limit to how many static entities and records you can create, but I'm unsure of the performance once you reach a large number. How many records do you have right now? How many records do you need for each section/feature of your application?

I'd recommend that you reconsider your current architecture - it's one thing to create a static entity to hold, say, navigation tabs and your application will need 10, maybe 20. If you're using records for too many things, not only might you find performance issues, but you'll also have a maintenance nightmare.

If you feel like sharing a snippet or example of your implementation, we could assist you in finding alternatives and maybe offer some refactor ideas.