Quote:Original post by soitsthateasy
Use server-side validation ONLY! Try the php htmlentities() function.

Sound advice, apart from that I think you meant to write addslashes().

Even then, that's a form of input sanitation, not input validation.

Quote:Original post by Alex131
My question is: "What should have better performance - storing the tables in php session variables or connect to the database and alter it's contents every single time the user does a quest?" I ask this because I've heard and read that MySQL should be used as less as possible to achieve a higher performance, but I don't know whether such a great deal of information for every single user who logs in won't slow down the server.

I think this advice is merely to counter over-zealous use of the database, where you fetch and write persistant state multiple times per page view.

There *are* cases where you want to buffer such data in RAM (with APC for example), however they are far and in between.

Even highly performance optimized web apps usually [unless they are using stateful web technologies like some Java stuff] perform multiple SQL queries per page view:

- to get the key data about the current user (which is what you mean)
- to find out which URL maps to which resource/page
- additional queries to make sense of that stuff
- yet more queries to perform actual work

...and they still run fast (< 50 ms).

Quote:Original post by chbrules
MySQL would also scale better if your game grows in popularity.

Not quite, as you can distribute sessions across machines using memcached.