Avoiding database calls by hardcoding data into script

Question

I've got approximately 1000 rows (4 fields) in a MySQL database. I know for a fact that the data in the database is not going to change very often (they are GPS coordinates). Is it better for me to call this information from the database every time the appropriate script is loaded, or would it be better for me to "hard code" the data into the script, and when I do make a change to the database, simply update the hard coded data too?

I'm wondering if this improves performance, but part of me thinks this may not be best practice.

Thanks

Answer 1

Given the fact that changes might occur once or twice per month, and the fact that 0.0063 seconds isn't very much (at least not from my point of view, if it would be a matter of life or death or very important Wall Street stock data that would be another matter), my recommendation is that you use the SQL. Of course, as long as you perform the query only once per script execution.

Indeed, it could improve performance with some milliseconds if you hard-code the data into your script. But ask yourself the question: How much extra work is needed to maintain the hard-corded data? If you really want to be sure, then make a version of the script where you hard-code the data and execute the script 1000 times and measure the time difference. (However, just making this test would probably take more time than it would save...)

If your script is run 5000 times per day and each time the SQL takes an extra 0.01 seconds compared to having hard-coded values, that's a sum of 50 seconds per day in total for your users. However, for each user they will most likely not notice any difference.

Answer 2

Hard coding coordinates into a script is not a good idea.
I would read the 1000 coordinates at start into an array, either from SQL DB or from a File.

But do that reading only once at start up, and not at each caluclation step.