1

Assumption
I understand that it's not good to store to much data and it is needed to be as simple.

State today
Now I use as minimum needed and using simple data types (int and strings)
mainly for storing user's id and to tell if he is logged in.

must of my functions are static or singleton that has to be built each post/get.

I have trouble to representing the current state and changing it.
and get a largely static site.
most of state representing goes into javascript .

Target
for the other hand if I'll create a object that represent the entire website it will be much easier for me to maintain user's input , including database interaction.

simple question, how much data should be stored there?

example

One of the things i want to implement is objects that relate to Database tables,
Let's take a page for a "car.update()".

Now if i store an object for it, that extends a connection to the Database with methods
for CRUD.

When I handle a post back from that page with details i could just put them in properties needed and call the update method.

situation now: I need to create a new object with that details and make an static update

Another example

storing previous search result and filter it using new data

shevski
  • 1,012
  • 1
  • 10
  • 32
  • You cannot store a database connect not in the session, nor anywhere else. Go figure – Your Common Sense Dec 21 '10 at 18:31
  • so MySQLi representation as object is just syntactic? – shevski Dec 21 '10 at 18:33
  • Dunno about mysqli, but it's because of PHP nature, which you'd better to learn first, before devising monstrous classes. – Your Common Sense Dec 21 '10 at 18:38
  • nothing monstrous, just wanted to implement a simple and dynamic behaviour and not mainly functional and static. – shevski Dec 21 '10 at 18:41
  • 1
    even if you could somehow store a database connection in the session it would be a bad idea. One user would then continue to tie up a database connection even when inactive; your database server would rapidly run out of connections and your site would be inaccessible even with a small number of users. – El Yobo Dec 22 '10 at 07:08

4 Answers4

3

In many cases the ideal amount would be none. Store the username in a cookie along with an HMAC hash used to verify the cookie was created by your site, and get everything else from the database (or cache) as needed. This makes it easy to load balance across servers because any server can handle any request and there's no state that needs to be shared between them.

This approach wouldn't be appropriate for banking or other top-security uses because if someone gets your cookie they connect as you. But for sites where you're not doing anything super critical it's great. The risk can also be mitigated somewhat by adding an expiration mechanism to your cookie handling. See chubbards great answer related to another HMAC question for more info.

Community
  • 1
  • 1
Brad Mace
  • 27,194
  • 17
  • 102
  • 148
1

note you can switch the way PHP stores data using session_set_save_handler. Then you don't have to change the calls and you improve performances/maintenance with the efficiency of database.

Mathias E.
  • 471
  • 3
  • 5
0

The minimum would be the user I.D.—assuming it is a logging in type of interface. But it is often helpful to include the most common aspects of that, like the user's permission and other items which are stored in the database, but are frequently referenced when constructing pages.

wallyk
  • 56,922
  • 16
  • 83
  • 148
0

You shouldn't store an enormous amount of data, but you can without problems store some user-information if it helps you server you pages faster.

But if you want to build a more dynamic website, you will probably retreive more and more data from the database. So when you're connecting to a database after all, you could skip storing all kinds of information in the session, because you can just as well get them from the database. Most databases (including MySQL) have a quite efficient query cache that will make repeated queries lightning fast.

So in that case you'll need to save little more than the userid and maybe a small amount of flags.

GolezTrol
  • 114,394
  • 18
  • 182
  • 210
  • you mean storing data that's related to website state in that Database? – shevski Dec 21 '10 at 17:44
  • It depends on the kind of data and the number of concurrent users. It will not be a problem to save a few hundreds bytes of information in the session, but when it becomes more, you might want to save it somewhere else. But I wonder how much and what kind of data you want to store. – GolezTrol Dec 21 '10 at 17:48
  • added two examples, the site itself is for somewhere of hundreds or a thousand people at most. – shevski Dec 21 '10 at 18:17
  • 1
    The examples you provide relate more to the database than to the session. I would store these values in the database. I would not store things like search results in the session because that is way to much data. As I said, executing a query a second time will make MySQL retreive the result from the cache. In most cases this means the query will execute in milliseconds. Also, when editing data, you should store it in your database as soon as possible to prevent data loss. There are always nuances, but that's a general rule of thumb. – GolezTrol Dec 21 '10 at 18:23