Storing in $_SESSION[] vs. Loading each time

TheoGB

Okay,

Just interested in some advice and viewpoints here.

I'm looking at building up a form of schema for my database to pass into both my model and controller classes so I have a central representation of the database (required fields, foreignn keys, formatting, etc.).

This will be built up by reading a folder of one array per table, writing each to a class and building an array of each of these classes.

So, PHP's stateless nature means that either I run the code to generate this each time or I generate it once per user's session and put it into the $_SESSION store...or something else?

P.S. I assume this sort of schema thing has been done many times before but I'm not bothered about reinventing the wheel as this is all about me learning techniques not writing professional PHP packages. But yeah, if this has been done before I'd be interested to see other examples.

Thanks

dalecosp

Warning: I approach this from an uncertified self-taught position.

But isn't the "central representation of the database" the database itself?

I'll continue the dialogue: it's server load vs. server load, disk access vs. disk access. But, since PHP is going to run each time a page is served regardless ... I might just use [man]include/man or something like it.

How's that for a brain-dead/missed the point response?

Sorry :o

TheoGB

The database is not in PHP, though. 🙂 If I can get that full information from the database by a single call and store it then fair enough, but I'm talking about the information that will be used to build the screen and to match the fields in the screen form to the fields I'll be updating on the database, etc.

Yes, the DB is the database but I'm talking about something in the PHP code that tells me about the database and informs my controller and model about the data I have.

In terms of the question I've asked, using the $_SESSION[] will mean keeping this data in the memory for the given session so it won't be loaded from disk each page refresh, only once per session. However, I guess this is also intrinsically less secure so probably not something we want to have in there. Maybe I'm wrong on that view, though?

dalecosp

But $_SESSION isn't necessarily stored in RAM. That's up to the HTTP daemon to decide.

TheoGB

dalecosp;10968509 wrote:
But $_SESSION isn't necessarily stored in RAM. That's up to the HTTP daemon to decide.

Fair enough, but in that case it's probably no worse then reading and then calculating to build, at least, yeah?

dalecosp

As I said at first, I'm not sure I'm qualified to get into this sort of design discussion.

I am sorry no one else has chimed in ... I might've expected one of the real heavyweights to "weigh in" by now.

bradgrafelman

I'll "weigh in" (not that I really consider myself a "heavyweight") with a couple of comments, the first regarding this:

TheoGB wrote:
using the $SESSION[] will mean keeping this data in the memory for the given session so it won't be loaded from disk each page refresh, only once per session.

If I'm understanding that statement correctly, then that is an incorrect statement. Every time a user makes a request to a PHP script that uses session data, the following process happens (assuming you're using the default file-based session handler vs. a DB-based one):

PHP looks for a file in the session.save-path directory matching the given session ID.
If the file was found, PHP opens it and reads the contents to build the $_SESSION array. If it wasn't found, PHP creates one.
The $SESSION array is available for read/write operations throughout the duration of the PHP script. All operations are performed against a "working" copy of the session data in memory (i.e. RAM).
When the PHP script is terminated (or a call to [man]session_write_close/man is made), PHP takes the "working" copy of the $_SESSION array and writes its contents to the file in the session.save-path

dalecosp wrote:
But $_SESSION isn't necessarily stored in RAM. That's up to the HTTP daemon to decide

Eh, not really. The HTTP daemon doesn't really have any control over PHP-specific things. Basically, when a request comes in for a PHP script, the HTTP daemon invokes the PHP interpreter and essentially hands all control over the request over to PHP. The PHP interpreter then returns data (both headers and the body of the response) back to the HTTP daemon which then relays the data back to the user in response to the request.

The only thing that could supersede PHP in regards to what is in memory would be the OS/kernel (i.e. context switching), but I'm ignoring all of that at the moment for the sake of simplicity. :p

@: Have you ever heard of Hibernate? I realize that Java != PHP, but it sounds like what you're wanting is the core function behind Hibernate. In a nutshell, Hibernate takes your DB and creates an OOP-style representation of it in code. You instantiate and interact with objects that mirror the structure of the relational database that they represent.

EDIT: After a quick Google search, it looks like Doctrine and Propel (not the drink :p) might be Hibernate equivalents for PHP.

dalecosp

Thanks Brad. How about, "heavy brain on a skinny body"? :p :evilgrin:

Maybe that'd be more accurate? 😃

TheoGB

bradgrafelman;10968528 wrote:
@: Have you ever heard of Hibernate? I realize that Java != PHP, but it sounds like what you're wanting is the core function behind Hibernate. In a nutshell, Hibernate takes your DB and creates an OOP-style representation of it in code. You instantiate and interact with objects that mirror the structure of the relational database that they represent.

EDIT: After a quick Google search, it looks like Doctrine and Propel (not the drink :p) might be Hibernate equivalents for PHP.

Cheers Brad,

I'll look at those and see how it should be done. 🙂 It's quite fun to try and think these things through.

I'm guessing from this discussion that I may as well just build the information up each time, then.

Thanks guys.