For a long while I disliked the use of objects or even classes (statically called) wrapping DB functionality as I found the mismatch between relational data and class grouping more confusing then benefital so I stuck strictly to functions.
I've played with ORM investigated my own design/implementation and have concluded (as of now anyways) I dislike it. I like the idea of keeping my tables bound to a single class/object so long as all that object does is work on the table it maps. When working in a relational model such as that offered by RDBMS like MySQL you often find that relational theory points you in one direction while OOP points you in another.
When joining tables, using objects I find I often end up with convoluted code, with objects depending on other tables because relational theory tells you thats best practice (DB normalization) while this very effect is frowned upon when working with OOP.
Having favoured OOP & good design over performance I started using static methods inside classes. Startinging off as basic CRUD operations I then experimented with trivial queries.
This approach took me in the direction of using PHP to specify relationships rather than depending on SQL, which had the bonus of keeping dependencies at a minimum, wrapping tables with a class to keep things organized and yea, tying all the peices togather using PHP rather than SQL. So far (nothing overly complicated) I've been pleasantly surprised. While this works against using a RDBMS (maybe I should switch to FoxPro or non-relational storage) like I said, I've been more than happy not having to keep track of SQL dependencies - I find it much easier to work in PHP.
Some might argue this is a sign of not planning a schema well enough and thus is the reason for my volatile SQL and problems with intra-table dependencies. In my experience it's the data model which is the most volatile of all components of a system, so why not and reduce headaches in that area?
Like I said, so far it's been pretty trivial SQL dependencies, so this might not even work in all situations, for instance:
When creating a entertainment web site which lists bands, tour dates, etc each which rely on the other....and performance is impetus, maybe using SQL would be justified. But in my applications where the user base is limited it makes sense to express table relationships using PHP rather than SQL...
Not sure what my intention is with this thread...we'll see what happens
Thoughts?