Storing info in $var against a cookie

I have a config.php file which I use to connect to my database.

Within this file I also have variables such as $sitename, $siteurl etc. I use these in my other pages so I don't have to always type in the same link information etc.

I was wondering whether to store this information in my database however. On the one hand saving the info in variables on my config.php file is quick and easy. However I thought that saving a database in a database is that bit more secure.

I wouldn't be saving anything secure in the config.php file - no passwords etc; only sitename, url etc...

Any thoughts on which to use?

Moved From The Codebank

Oops sorry, didn't realise it was in the wrong place!

My preference (and typical practice) would be storing it in a file, and using define() to make constants out of them.

Why do you make db tables? To have records of strongly-typed data so you can organize and use them in a meaningful manner. While this doesn't mean you can't have a table that has columns like "settingName (str)" and "settingValue (many data types stored as... str? blob?)", there's not strong reasoning as to why it should be a table.

As for security, no one's going to see your PHP variables unless you explicitly output them. I don't think storing the info in a database is any more or less secure than putting it in PHP.

But, others may offer you different suggestions.

Thanks Samba - that's another idea I didn't think of - using a file!

Can you show me sample code on how this would be used? Would it just be a text file? I wouldn't need any code to write to it. I'd just use notepad (or whatever) to edit the file and then PHP would read it.

Not a text file; a PHP file that you include on all pages - it sounded like you were already doing this with config.php?...

But it would simply look like this:

Code:

---

<?php
define("SITE_NAME","My Awesome Website");
define("SITE_URL","http://www.example.com");
?>

---

It's conventional practice to name constants with all capitals. You can also define things like your SQL host and login credentials, any paths you might use regularly, etc. Since you're including it on every page, this file is also a good place to put any custom functions you've made that will be in use throughout the site.

On your site pages, put an include (or probably a require() or require_once()) at the top, then refer to your constants using the name you've defined them with:

Code:

---

<?php
include("global.php");

echo "Welcome to ".SITE_NAME; //outputs "Welcome to My Awesome Website"
?>

---

I see what you mean now - yep, that's what config.php is basically used for, although I'm just doing:

Code:

---

$sitename = 'www.sitename.com';

---

Is it better to define such things as constants, and if so - why?

Going back to the topic of my question: where would it best to use a table/database to store information and where would it be better to store in a file? What are the advantages of each method.

What I'm thinking is that I will store data which can be manipulated by my users in a table. Important variables (globals) will be saved in a file. Of course there is a crossover, but am I on the right path?

Storing information in a file (flatfile) is fine provided the information quantity is small. If it's quite large however then a database is better since they are usually optimized for those types of end cases.

The advantage to flatfile is that it's portable and you can customize the format to do what you want. The advantage to a database is that it has better performance when dealing with large data sets and it's generally easier to manage.

Which you use depends on what you're intending on using it for really.

Quote:

---

Is it better to define such things as constants, and if so - why?

---

The two main benefits to constants are that they have global scope, so you can use them anywhere, and that their values cannot be changed by your script. While it's true that you could create a global $var and remember not to change it, both of these rules apply to constants by default, so there's no messing it up. If you follow the uppercase naming convention, it also visually demarcates something different when you see it in script.

With databases, I decide what goes into them (and how to structure tables) by an object concept. Say you have a table for customers - each row will conceptually be a customer object, with the columns pertaining to the object's properties (eg. their name, last name, address... information about that customer). This would apply to your proposed user table as well: each row is a user object, and users have permission to alter information only within their own scope (table row).

This sort of information would be terrible to store in files because you'd have to manually maintain the relationship between a user and all of his data... and do that for every user you have. You would also lose functionality that lets you deal with users as a group: sorting them by a column, comparing them by certain data, etc.

But global variables don't fit into that model; they don't belong to a particular user, they belong to the global scope. Nor do they relate to each other (in an intuitive manner) or need to be sorted, compared, etc. As said, you could make something of a "settings" table to define vars for your global scope, but it just seems like shoehorning to me.

[As an aside - the other primary table type (aside from "objects") is for storing relations between objects. For example, linking a customer record to the potentially multiple order records they may have (though this is bad example considering that an order would only ever have 1 customer associated with it, so a single relational field would suffice rather than a table, but let's ignore this parenthetical text!).]

I am not the most elegant in expounding on concepts.

Thanks Samba, everything you wrote makes sense to me. I'm going to keep my 'settings' in a config.php file and define constants. Cheers,

The chief problem with storing settings in a database is that you need to store the database connection settings somewhere...