Jump to content

storing variables in $_SERVER


Brian W

Recommended Posts

Why (if it is) bad practice to use the $_SERVER array to store variables like the database hostname, username, password, etc... or even a mysqli object?

 

I know the whole anti lazy coding, but is there another reason not to go about things like this?

Link to comment
Share on other sites

You really need to explain your question. The $_SERVER array is just like any other array accept it comes pre-populated with some variables based on your environment. You can't exactly *store* anything in it. Nothing that will persist across requests anyway.

Link to comment
Share on other sites

The only benefit I see is to save memory - although the saving is hardly worth the work. I suppose you have the global factor too.

 

Instead of server though, there is an array called $_ENV.

 

 

Try the following 3 small scripts to view memory usage:

<?php
putenv("TEST=1");
echo memory_get_usage();
?>

 

<?php
$test=1;
echo memory_get_usage();
?>

 

<?php
$test="1";
echo memory_get_usage();
?>

 

I'm not sure if putenv() saves as bool or int, hence the reason I done the two scripts for $test variable - both with different memory usage.

 

You can access the variables in two ways.

 

echo $_ENV['TEST'];

 

echo getenv('TEST');

 

 

I don't know why using these techniques would be classed as bad practice. Maybe its just some sort of unofficial standard?

Link to comment
Share on other sites

Interesting, $_SERVER is quite bulky...

My Results

Base	83144
putenv	83496
1	83552
"1"	83584
$_SER	94896

 

Multiple uses of $_SERVER did not increase the memory usage noticeably, but that first time does jump it. So PHP seems to ignore populating it unless you actually use it in your code.

 

putenv doesn't seem to be required to drop stuff into the $_ENV global. I did this little test this morning:

<?php
$obj = new stdClass();
$obj->name = 'test';
$_ENV['obj'] = $obj;
function test(){
    echo $_ENV['obj']->name;
}
test();
?>

 

The memory usage is lower than $_SERVER (86632) but if you plan on using $_SERVER anywhere in your code you will end up using the memory.

 

For a programming convention, not that globals aren't still under scrutiny, is a database connection more of a $_SERVER thing or a $_ENV?

Link to comment
Share on other sites

For a programming convention, not that globals aren't still under scrutiny, is a database connection more of a $_SERVER thing or a $_ENV?

 

Your still missing the point. You could use a normal self created array. $_SERVER does not persist content you have added to it across requests. $_ENV will if you actually add these values to your environment through Apache directives.

Link to comment
Share on other sites

$_SERVER has a special meaning - it contains "server variables".  If you put other things inside there then you are changing its meaning.  This will confuse other programmers who modify your code later.  It also may break code written by other people which you integrate into yours, as they may assume that $_SERVER is used for its intended purpose only.

 

If you will be the only programmer who ever uses your code, then I don't see any problem with using $_SERVER that way.  But if I ever maintain your code, the first thing I will do is take those variables back out again :)  It's a maintenance time bomb.

 

If you want a global variable, you can create your own.  There's no need to use an existing superglobal.  It would be convenient if PHP allowed user defined superglobals, but probably a bad idea, as I think it's better if you're forced to declare globals in each function you use them, which clarifies what external variables that function needs.

Link to comment
Share on other sites

Drupal uses the $_SERVER superglobal to store connection information (though not the connection object itself that I know of). This does seem to be a valid use as what you are storing is the connection information for the mysql server. Maybe not, maybe Drupal's architects are missing the point too.

 

Using mysql_connection(), you can use most any of the mysql_* functions without passing in the connection resource which makes it an easy choice... mysqli however isn't as friendly, though its so much faster and (imo) fits in with oop better. From my understanding, using the persistent option with mysqli will cache the connection and reuse the same connection repeatedly until the request is done. If this is true, a factory wouldn't need to access a global connection object because their would be very little resources sacrificed for mysqli to return the cached connection repeatedly.

 

I'm thinking that using a persistent connection and storing hostname, username, password, and database in $_SERVER is the solution, but then again I'm not all that familiar with building factories... I did see a tutorial using the "singleton" structure, but didn't fully get it I guess. Maybe someone has a link to an awesome singleton for mysqli

 

Thanks for all the input!

Link to comment
Share on other sites

Drupal uses the $_SERVER superglobal to store connection information (though not the connection object itself that I know of). This does seem to be a valid use as what you are storing is the connection information for the mysql server. Maybe not, maybe Drupal's architects are missing the point too.

 

Drupal is definitely not the first thing that comes to mind when I think about well designed applications.

 

I'm thinking that using a persistent connection and storing hostname, username, password, and database in $_SERVER is the solution

 

Have you ever heard of constants? These are perfect for storing simple strings and accessing them from anywhere.

 

I did see a tutorial using the "singleton" structure, but didn't fully get it I guess. Maybe someone has a link to an awesome singleton for mysqli

 

There is an entire series covering the basic design patterns on our main site (http://www.phpfreaks.com/tutorials/page2). There's an article there covering the singleton.

Link to comment
Share on other sites

This thread is more than a year old. Please don't revive it unless you have something important to add.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.