Not for 'how-to' coding questions but PHP theory instead, this forum is here for those of us who wish to learn about design aspects of programming with PHP.
Every time somebody posts their mysql interaction class on this forum (and it seems often) the response is... keep it minimal. I am wondering if this is too minimal... am I missing something... missing the point? Please nitpick!
Looks ok. I've found that the database connection code should be in a seperate class, that way you can run more than one instance using the same database connection. The db class I wrote has a lot of bloat in it, but I like it because it saves sooo much time when I do long inserts and selects.
thanks... I hadn't even tested out that query method before I posted it... and I like the idea of using a seperate class for connection... I am working on that now. Any suggestions for methods in the class other than the ones there though? (I am going to add a close method, but anything else?)
My *sql classes contain an iterator for the results (results are stored in an array - which I use an object for as well, but essentially it's just the same as normal array as per below):
I'd say get rid of the connect() and select_db() functions.
You're never going to be instantiating this object without wanting to connect to the database, so why not put that in the constructor?
The same applies to the select_db() function. You're passing along the DB to the constructor, why not just connect & select the DB there?
Real programmers don't comment their code. If it was hard to write, it should be hard to understand.
astions wrote:Looks ok. I've found that the database connection code should be in a seperate class, that way you can run more than one instance using the same database connection. The db class I wrote has a lot of bloat in it, but I like it because it saves sooo much time when I do long inserts and selects.
I think that may be a bit of an overkill. Perhaps provide a method of fetching a singleton instead.
this class is going to be used strictly by other (more specific) classes... so the point of it is to:
1. Connect to the database (but only if a query is ran... not auto-connect, which is why mysql_connect isn't in the constructor)
2. Run (select) queries and return the results in a neat format
3. Execute (update, delete, etc.) queries and return whether or not it was successful
That's basically it. I don't want it more complicated than that.
The Ninja Space Goat wrote:this class is going to be used strictly by other (more specific) classes... so the point of it is to:
1. Connect to the database (but only if a query is ran... not auto-connect, which is why mysql_connect isn't in the constructor)
2. Run (select) queries and return the results in a neat format
3. Execute (update, delete, etc.) queries and return whether or not it was successful
That's basically it. I don't want it more complicated than that.
Why not establish the connection once, and use d11's suggestion of adding a method to return the instance of the class?
I have tried to create a singleton before and failed (I am doing something wrong, and I Can't post my code right now because it's at home). I like the idea though... I will work on doing it that way. Then I need to somehow get my registry to accept singletons.
The Ninja Space Goat wrote:I have tried to create a singleton before and failed (I am doing something wrong, and I Can't post my code right now because it's at home). I like the idea though... I will work on doing it that way. Then I need to somehow get my registry to accept singletons.
Your registry shouldn't care if the object is a singleton.... it's still an object. Then again, I'm not sure I've seen how you've written your registry. Is it a factory as well as a registry or something?
As for allowing a singleton to be fetched it's just a case of adding a static property to the class and a static method to return that. Think of static properties as encapsulated globals (which is why some people don't like them!) in this scenario.