PHP sessions for storing lots of data?

Question

I'm developing a media bookmarking site and am looking for a way to remember whether a user has bookmarked an item (without having to go to the DB every page load to check).

I haven't used PHP sessions before, but I'm thinking they would do the trick.

Would it make sense to do an initial DB call when the user logs in, grab all the items that a user has bookmarked and save an array of all the item ids to the user session?

Then when a page is loaded, for each of the 100 items on the page it would check whether that item's ID is in the session array (so we know whether to display the "bookmark" button or an indicator that they've already bookmarked it).

Just want to make sure this is a right strategy, or if there is a better way. Would this work fine even if there are 10,000 ids in the array?

Answer 1

I would suggest you look into a DB and not store this data into a session. You will clog the memory really fast on a high load site if you will have lots of information in there. Just do some caching and you should be fine.

Answer 2

Bear in mind that a common PHP strategy for increasing the robustness and speed of session management is to store session data in a database. You seem to be headed in the opposite direction.

Answer 3

Well, if you want to do something ridiculous, you could store all the data on the client's browser using Javascript, in some object that survives page-changes. I wouldn't recommend it, since it adds a lot of headache to you, but I figured with all the weird AJAX-y solutions out there, it might be of interest :-)

Answer 4

As well you can take a look at Memcached extension - it uses server's memory as data storage.

Answer 5

Storing data in session also means that the data will be lost after some 15 minutes (default, but can vary).

Imho you should save the data to a DB, then use some caching for subsequent reads (i.e. memcache, as @Mark Tyler said).

Answer 6

I would recommend using ADODB for php. It has built in query caching and sql injection protection etc. You can read more about the caching features at http://phplens.com/lens/adodb/docs-adodb.htm#caching

Answer 7

The best solution here is to have a favorite/bookmark table in your database, have it contain the user_id and the item_id and add a join to your item retrieval logic.

Then you don't need to run additional SQL commands nor store anything in session, you only need to check for the existence of these favorite columns.

Answer 8

Don't overestimate how bad going to the database once per pageload is. You'll find lots (and lots) of PHP applications that do what you're talking about. Lots of applications pull various parts of the page from the database, get user data, forum data, news, etc. etc, so a single page load could be running ~30 queries.

Store a unique ID in the cookie, and store the session information that you want to store in a smart way in the database.

You might be thinking too far ahead. A good approach here would be to build the functionality you need in a sensible way (i.e. server side), monitor your system resources (db load, web server load), and then if you do notice a problem, refactor to solve it.