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
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.
Afonso Carvalho wrote:
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.
Lovish Goyal wrote:
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 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.
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.
Hi Afonso Carvalho. How many records in static entity considered to be large number? We have about 200-300 records in static entity and having doubts regarding if it is reasonable to have it static or transform to normal entity. Is there a way to check if it is impacting performance in any way?
Thank you
Hi Mykola,
200-300 records in a static entity looks too much to me, and I would seriously consider using a normal entity instead. It could be that your use case justifies it though. Would you mind sharing a little about the purpose of that static entity?
There's no specific logs that you should check when thinking of static versus normal entities, just looking at query times involving that entity should be enough.
We have kind of hooks in our app. So when specific action is executed we can have configured from front-end other actions that are called after the hook. In static entity we keep list of this hooks.
So you have dynamic, configurable behaviour, and you configure these behaviours by referring to the static values? That sounds reasonable, it's just that it's a lot of records for a static entity.
How do you control the flow, or how do you distinguish between static values within the code? Do you use switches?
A couple of years back I had a project that involved hundreds of dynamic workflows and what we did was a series of normal Entities that detailed the workflow steps, along with a couple of static entities that identified the types of steps, but they never exceeded 5-10 records. I would say that at a glance, a static entity with 200 records is definitely a sign that you should consider a refactor, but you'd have to judge how much work this would entail for your app. Building an engine that uses normal entity data for these sorts of dynamic configurations is considerably harder than relying on a static entity, but it could also make your maintenance easier, if you ever find the need to add more values.