"Paul M Foster" <paulf@xxxxxxxxxxxxxxxxx> wrote in message news:20090719220923.GV14822@xxxxxxxxxxxxxxxxxxxx > On Sun, Jul 19, 2009 at 03:56:43PM +0100, Tony Marston wrote: > >> Two things strike me as wrong with your thinking: >> >> (1) The idea that you have a separate DAO for each entity instead of a >> single generic DAO which can act for any entity in the system. >> (2) The idea that pagination requires its own class, and therefore needs >> this "is-a" and "has-a" nonsense. >> >> As for (1) even in my pre-OO days I was used to using a single generic >> DAO >> for all database access. The only time that more than one DAO existed was >> for a different DBMS engine. This is why I have one DAO class for MySQL, >> one >> for PostgreSQL and another for Oracle. If you are incapable of writing a >> single generic DAO then it just shows that you still have a lot to learn. >> For an idea on how this works take a look at >> http://www.tonymarston.net/php-mysql/databaseobjects.html > > This brings up a question. Most of the tutorials I've read on your site > deal with classes tailored to specific tables. However, in much of my > software, I have to deal with queries which access multiple tables. For > example, my invoice table contains the customer number, but not their > name. For that, I have to go to the customer table. Thus, my queries > often access multiple tables with where clauses which ensure I get the > proper data from secondary tables. I've never used "views" in SQL, but > it appears that this is what would be called a "view". > > So in your constellation of software, would you create a subclass of > genericTable which essentially is a "view"? Otherwise, how would you > handle this? > > Paul Such things can be handled automatically by my generic DAO. Amongst the details which are exported from my data dictionary into each table structure file (which is accessed by the database table class) is a list of all the parent/foreign tables, the foreign key field(s), and which fields to retrieve from the parent table. So when the sql SELECT statement is being constructed it can use this information to add a JOIN to the parent table in order to retrieve the specified field(s). This is documented in http://www.tonymarston.net/php-mysql/data-dictionary.html#sql.joins Any number of parent relations can be defined for a table, and any number of fields can be retrieved from those tables and added to the SELECT list. All the developer has to do is define the relationship in the data dictionary and the framework will handle the boring stuff of generating the necessary SQL. So, using your example, I would define my customer table as a parent to my invoice table, identify which foreign key field relates to which primary key field in the parent table, define customer_name as the field to be retrieved from the customer table, then sit back and watch the framework do its stuff. Each time I read from the invoice table the result would automatically include the customer name. Easy peasy lemon squeezy. It's not rocket science, but it is neat. -- Tony Marston http://www.tonymarston.net http://www.radicore.org -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
