|
|
Posted by Tony Marston on 02/20/07 10:42
<rpsetzer@yahoo.com> wrote in message
news:1171888343.626985.121040@v33g2000cwv.googlegroups.com...
>I have to create a big web application and I was thinking of using a
> data layer. For each entity in the database, I'll define a class that
> maps the table structure, having sub-objects for each foreign key,
> having insert/delete/update methods, the usual deal. Yet, I am very
> concerned about performance. For example, there are lots of cases when
> I may just be needing the employee name. Yet using this model, I will
> have to instantiate an entire Employee class, which may have sub-
> objects and use lots of SELECT queries. I think this will be an
> important performance hit. What do you think? Ever did something like
> this? Is it worthy? Is there a better way? Should I give up creating
> the data layer?
>
Having a single class for each database table is a good idea - I have been
using it for years. The notion of having a subclass for each foreign key is
a definite no-no. It is totally unnecessary and a waste of time. Nor do you
need a separate class method for each possible SELECT ... WHERE ... as it is
possible to have a generic getData($where) method where the $where argument
is a string which is provided at runtime. This can cover all eventualities.
It does not matter that you have to instantiate the EMPLOYEE class
containing 40 columns if you only want a single column. In my methodology
the default is SELECT *, but a specific list of column names can be provided
for individual queries if required. This removes the need for a different
class method for each combination of SELECT ... and WHERE ...
One thin that you should notice is that 95% of the code in a database table
class is common to all database tables, therefore this common code can be
put into a superclass and inherited by individual table classes. This means
that each individual table class need contain no more than the following:
(1) database engine name
(2) database name
(3) table name
(4) database structure (column names, primary key names, candidate key
names, relationships with other tables)
(5) custom business rules
If you are really clever you can put your database APIs in a separate class
so that you can switch database engines (MySQL, PostgreSQL or Oracle) by
changing a single line of code.
The bottom line is that if you use OO classes intelligently you can save a
lot of repetitive coding, must don't waste time trying to create a complex
class hierarchy - it just ain't worth it.
--
Tony Marston
http://www.tonymarston.net
http://www.radicore.org
Navigation:
[Reply to this message]
|