ordinaryToucan

(Using MySQL5.0) I have a question, for which I would be grateful to receive wisdom / opinions / ideas... I want to store basic details (email, firstname, lastname, etc.) for about 50,000 users - about 20% of which will include (up to two) postal addresses. Is it better to store the user details and user addresses in separate tables, or in a single table?

No, it's on a dedicated server, but the client has a paranoid system admin who won't allow me anything more than ftp access! Plus the setup on their server is a mess, and I don't want to do anything that causes their installation of Plesk to fall over!

Wow, thanks for the response. I'm learning more here in two days than I have in several years of reading PHP handbooks! What I had done was to create an Input object and a User object in my Main output object, each of which were aware of the properties of the Main output object. So for example (and briefly!): // main output object class Main { public function loadInput() { $this->input = new Input($this); $this->input->sanitizeAll(); } public function loadUser() { $this->user = new User($this); $this->user->getSessionUser(); } } Then within the User class I had... class User { public $username public $email // plus other properties public function __construct(Main $main) { $this->main = $main; } public function getSessionUser() { $this->current->username = $this->main->input->session->username; // getting session data that has been sanitized by the input object; $this->current->email = $this->main->input->session->user_email; // getting session data that has been sanitized by the input object; } public function login() { $this->main->database->newQuery('user'); // creating a new user object within the database object; $this->main->database->user->setSql("SELECT * FROM users WHERE username='{$this->main->input->post->username;}' AND password='{$this->main->input->post->password}'")->getResult(); // then go and set this user's details into the current session etc. } } Now, I understand what you're saying about having a separate user object and authentication class... but I think my confusion arises from deciding the best way to get classes and methods to relate to each other? Am I going about this in completely the wrong way – allowing them to access each other's properties and methods? For example, in the Main class I have a single Database object which represents the database (and connects to it) and I create new Query objects through a "newQuery()" method within the Database object. In your Authentication class would it have to be aware of the database object / connection held in the Main class? Many, many thanks for your help. I REALLY appreciate it!

Thanks guys, that's fantastic advice and really appreciated. I have reworked my app as suggested, to make a single connection on the first database query which seems to stay open until the end of the script - the execution time on each page is quicker and the code is neater too! I've never actually worked with caching data before, but I think it's a valuable suggestion. I have a quick question about the best way to approach the security aspect of caching...? Site settings, for example, I guess could be written to a file whenever they are changed, and then called from the file (rather than the database). But given that I don't seem to be able to write to any directory that doesn't have 777 permissions, what's to stop some ner'do'well grabbing the file and making a mess of it (or worse)? The particular server that the site will be on is not administered by me, so I don't have any choice over open base dir and safe mode settings. Again, any insight from those with experience is very gratefully received!

I think a phpfreaks tutorial has just answered my question... I have now created sub-objects that are aware of the master object by throwing the master object to the sub-object. I had no idea that this was okay... but it seems to work, and I'm happy with it too! I have a lot to learn!

I'm not certain whether this comes under coding or application design (forgive me if I'm in the wrong area) but I have a bit of confusion the best way to share properties / values across multiple objects that all live within a master object... or for objects to get properties of the object that has called it. For example - index.php creates a new Output() object. The Output class creates instances of various objects. Some of these objects have properties that overlap. The properties of an Input() object that sanitizes and stores all GET / POST / SESSION / COOKIE data, might need to be accessed by a User() object that checks the current user details; or by a URL() object that splits the URL into segments; or by a Database() object that is called to store or retrieve data from the database - which might in turn need to refer to any of the data in the other object. There were three ways I though of doing this: One - Create once massive class that contains all the methods and functions needed. This is possible, but probably not in the spirit of OOP! Two - Throw parameters (the old-fashioned way) to the sub-object's methods. (eg. $this->user->login($this->input->sanitize($this->input->getPOST('username')) This seems safe, but somewhat negates the point of OOP in that there are lots of methods that I would like to be able to refer to the master objects properties without having to explicitly state them! Three - Create a reference to the master Output() object in each sub-object's constructor (eg. global $output; $this->output = & $output). This appears to work... but I don't know whether it's safe that the sub-object contains the master-object Or do I have my application design complete about-face? This is driving me totally nuts.... Any opinions would be VERY gratefully received!

Hi There, I'm developing for a web site that requires multiple bits of data from the database for each outputted page (eg. site settings parameters; module settings; page content; sidebar content; etc.). At the moment my script creates a new "database query" object for each query, which in itself creates a connection to the database, sends the query, and parses the results. That means that a new connection is created and closed for each query... Now I am wondering is it better to 1) Open and close connection for each query within the script; 2) Open a pconnect for each query within the script; 2) Open a connection at the top of the script and close it at the end of the script; I seem to be able to find arguments for and against each method, but I am wondering which is likely to be the most efficient in terms of maximum number of simultaneous outputted pages. This site this is for is usually quiet but occasionally gets large numbers (thousands or tens of thousands) of hits in a few minutes. The setup is PHP running as an Apache2 Module, with the database on the same box. I'd be very grateful for any insights.

I apologize for yet another OOP-newby question! I've read numerous tutorials and explanations of OOP, and I understand that it seems to be a good thing because it creates code thats extensible, reusable, and many other programming languages use OOP. So as an experiment I created a mySQL database class (which includes methods for connecting and various methods of constructing queries) to replace the library of (procedural) database functions I was using already. However I can't see any particular advantage... and I hope someone can help me to understand why it will benefit me in the long run. For example: before, I had a db_query() function that connected to the mySQL server (using login variables from a config.php file), and if you threw it a mySQL query it also selected the db, performed the query, and returned the result. I could call this function from anywhere. Now, I have created a database class which includes a connect() method, a db_select() method, and a query() method which chains the first two together and then performs the query. Every time I want to use these I have to create a new database object... This all seems like more work and I can quite understand what I am missing...?