0

There can be potentially up to 1000 strings in total. Should these be hardcoded or stored in database? These are frequently accessed because everytime user wants to register or checkout an item, they are going to need to see list of area/suburb/province/countries.

If i have bunch of Enums, i think the performance should be fast because there is a max number of strings ~1-2k max.

On the other hand, if i store them in database, there's going to be latency accessing the database as well as cpu/memory consumption.

Which option do you choose?

user1955934
  • 3,185
  • 5
  • 42
  • 68

2 Answers2

1

1000 isn't a huge amount, and I would put this information into a text file and read them into the program on start-up.

Regardless, this is data, not code, and so should not be an enum (code). Why not enum? It's a lot easier and more flexible to update/change data than it is to change code, should this need to be changed in the future.

If you will definitely be updating and changing this information with time, especially if through multiple sources, then a database is surely the way to go.

Hovercraft Full Of Eels
  • 283,665
  • 25
  • 256
  • 373
1

It all depends on you. There is no proper convention. Below are 3 ways along with their pros and cons.

  1. Create a class with static final string variables. Pros: a. Very easy to use. b. Developers can do look ups from within IDEs. Cons: a. Every time you need to add/delete something, code will have to be recompiled. However, this will not be much problem if you have ci-cd in place.

  2. Add everything in properties file and load at runtime. Pros: a. Modifying things will be a breeze. No code recompilation required. Cons: a. This would still need re-deployment and server restart. b. Developers will be unhappy as they will have to refer the txt file every now and then. Also this could lead to mistake if developers use wrong codes which are not present in properties file.

  3. Use database Pros: a. Highly configurable. b. No need of re-deployment. Cons: a. Service restart will be required.

As you can see, service restart will be required for all of them as you will definitely going to use caching in case 2 and 3. My suggestion would be to use first option if they are literally never going to change as it is quite developer friendly.

Manish Bansal
  • 2,400
  • 2
  • 21
  • 37
  • no 3 shouldnt need a server restart i dont think? No. 3 is definitely easier, but it’s just that i feel the database is wasting resources unnecessarily.. another benefit of no. 2 is that in microservices structure, this file can be referenced in all the microservices... which one is your choice? – user1955934 Jun 08 '19 at 14:20
  • Option 3 will need restart if you are going to cache the value on server startup unless you add some mechanism to reset the cache on update of the values in database. Further, if you are going to use microservices e.g. spring boot then you should consider using spring cloud configuration. – Manish Bansal Jun 08 '19 at 14:29