[SOLVED] Question about speed mysql storing vs php array storing

[pkedpker]

Is it better to store 500 different strings of 100-200 characters each and call them on demand using mySQL or hardcode them in PHP in a huge array?

 

I am not worried about looks here just speed. I was thinking the PHP way but i dont know if that will slow down the whole page from being rendered more then just calling a mysql query.

[Ken2k7]

Depends. I would say MySQL is better. With PHP, it needs to compile the files per run/page request, so that can get extensive. And you can only store so much in a PHP array. It does use memory, you know.

[roopurt18]

With PHP, it needs to compile the files per run/page request, so that can get extensive.

If there's a PHP optimizer installed it may just optimize that kind of stuff away; it's hard to say exactly what the real impact could be without benchmarking.

 

If he's always using all of the strings then having them in a PHP array is probably more efficient than always pulling all 500 out of the DB.

 

My concern is why are you pre-optimizing your code?  Write it so that it works and let it go.  If you encounter problems down the road then do some profiling and fix the actual problems.

[Daniel0]

And you can only store so much in a PHP array. It does use memory, you know.

 

It doesn't use more memory loading it at compile time rather than at runtime.

 

If you always need all of them and they aren't going to change, store them as an array in PHP. Otherwise use a database.

[pkedpker]

Well I stored all 500 into a array and the php file is 20 KB.. so i dont believe its too much.. then I will store in other arrays for checking purposes just numbers..

 

I found many problems that you just cannot do without calling mysql like mad.

 

Say in DB.. I have a bunch of items to pick from and they are id (primary) iid (the id I use to determine each one) and avail (see if item is possible to take).

 

Now i check to show all items with avail=1 and then call another page with iid and id..

 

so could either make 1 query in the other page because I already have id.. i can just display the description linking it to my php file with all 500 strings. or I could just pass id.. and do 2 queries first to get id AGAIN etc..

 

but what I realized even doing it my way with 1 query.. there still has to be checks in place because people would be able to put in any id they want for hacking purposes.. so I'd still do 2 queries 1 to check num_of_rows to see if item exists (this is on page 2).. so much calls to mysql.. when running this off my test server it might cause problems. I was thinking of making it all flatbased but i dont see any reason for this kind of work as sooner or later it will still call mysql to save user related stuff.

[Daniel0]

Ever heard of JOINs?

 

http://dev.mysql.com/doc/refman/5.1/en/join.html

[pkedpker]

No no.. it has nothing to do with joining tables.. it just something I have to do.. because I call from different php files.. meaning like

 

 

show.php  (shows all items) click item which goes to another php file like display.php (which shows 1 item person clicked) which works like  display.php?item=### and I will have to check that ### with DB again.. it doesn't only display it actually says you are the current owner of that item even though I know its correct just to prevent hack attempts.