3

I have some JSON data in this format (5,000 instances for now):

{"id":"123456","icon":"icon.png","caseName":"name of case"}

I am allowing the user to search for the name of the case and then return the id and icon to them, and in some situations, use the case id to run other functions, based on the search.

How should I read this data? I'm currently leaning towards a switch because I want the switch to allow me to define multiple cases giving me the same result:

name of case and name-of-case should return me the id 123456

I can easily use a switch based on the string, listing out different cases, to do this. Probably going to be extremely tedious, but it's an option.

So, my options I can think of are as follows:

  1. Run a massive switch based on the query string (probably in a separate PHP file)
  2. Store this result in a MySQL database, then based on the query string, retrieve the data, and I probably need to do indexing (which I understand, but have no idea how to implement).

Also, I would like to prepare for the scenario that this 5,000 instances increases to 10,000 instances at some point in time.

What's the best way of going about this?

Thanks.

user3201185
  • 35

3 Answers3

7

Always use SQL. The amount effort to read the data from SQL is in your case of complexity similar with a query. So why bother to add extra code?

Adam Zuckerman
  • 3,725
  • 1
  • 21
  • 27
Adrian Pirvulescu
  • 194
6

If you take pride in your work, then:

  • the overhead of doing an database query every single time should disgust you
  • the idea of maintaining a massive hard-coded switch should horrify you

Most languages have support for collections and include things like hash maps, and this is likely to be very well optimised (and for languages that don't it's relatively trivial to implement anyway). This is what you should be using. For a collection of 10000 items it's extremely likely that you can find a value from your key faster than you can send a "do nothing" request to a database and receive a "nothing done" reply back.

The next question is, when you're creating the collection where does the data come from? This depends on the nature of your software - does it start once and handle many requests (like virtually everything that is sane), or is your software started from scratch every time (e.g. like the old CGI interface web servers used to use back when "internet connection" meant a dial-up modem; where every single "page fetch" would cause a massive amount of bloat starting a script interpreter, finding the script, letting the script initialise itself, etc).

For the first case you can do whatever is easiest for you to maintain. This could be loading the data for your collection from a "plain text" file or from the database. Performance doesn't really matter here because it only happens when your software is first started (which might be once every 200 days or something).

For the second case; you should ignore everything I've said above and do a database lookup every single time. Even though this should disgust you, anything you could do in your own software (starting/loading/initialising everything from scratch every single time) should disgust you even more.

Brendan
  • 4,005
4

Listing 10000 cases manually is a titanic work. You should use a database.

If more than one spelling is possible, you can use an Alternatives table, to fetch the canonical version of a case name.

lortabac
  • 1,442