Re: OOP database tables <-> php interface (semi LONG)


"Jerry Stuckle" <jstucklex@xxxxxxxxxxxxx> schreef in bericht
news:mpmdnf_eobam7ILbnZ2dnUVZ_riknZ2d@xxxxxxxxxxxxxx
amygdala wrote:

<snip>

And as you add more types and subtypes, this gets longer and longer. And
slower and slower. And harder to maintain and more subject to errors.

<snip>

And you'll have to add more custom validators plus hooks for them.

<snip>

And what about cases where you need non-consecutive numbers? Such as
those from the set (1, 2, 3, 5, 8, 13, 21...)? Another custom
validator...

<snip>

The generic will be much larger, much slower and much harder to maintain.

<snip>

Yes, it's easy to get one idea in your mind as the best way and stick to
it too long. You need to be flexible. Even after 40 years of programming
I sometimes have to change my approach because someone shows me a better
way.

<snip>

I create db objects all the time. But they have get and set functions for
each field (at least the appropriate ones). They are quite handy for a
number of purposes - the biggest one being abstracting the database
access. But then that's their major purpose.

For instance - one I'm on right now. I have a site coded in VBScript
using Access. I want to change it to PHP and MySQL. However, for various
reasons this needs to be done in stages. The Access database has over 30
tables, ranging from 2 columns to over 40 columns per table.

We're (others are involved - it's a big site) creating DB objects to
interface the Access tables. These will handle the actual SQL calls and
isolates the program from the database being used (or even flat files, if
necessary).

Next we'll creating business objects - these objects translate between the
program and the database objects, and convert what's in the tables to a
format the rest of the program needs. This isolates the rest of the code
from the database table design (i.e. if we need to change one or more
tables, this and the db objects are all that will need changing).

We'll then convert sections of the site at a time. Once we get a section
converted, we'll bring it online.

When we're done and can change from the Access database to MySQL, we'll
change the Database layer and move the data. If at the same time we need
to change some of the table design, this will be handled between the
database and business object layers. But any changes will be isolated to
those layers.

Note the business object layer isn't always needed. But due to the
complexity of the site and how many tables are interrelated, we decided it
would be better to use them here.

These are the benefits of database objects (and OO in general).
But I would hate to use your fieldspec idea in this case. It would make
things much harder to troubleshoot, and we'd end up with a lot of
specialized validators. The result would rapidly become unmanageable.

So we're putting in the set and get functions for several hundred table
columns. Additionally, we're doing a similar number on the business
object end. And depending on the data, it may be validated in either
level.


Some darned good points Jerry. Especially the getting too large and slow
parts are starting to convince me

Good point about the flexibility too! I try my best to keep up a flexible
attitude. The thing is though that I often get caught up in trying to
generalize things too much and/or mixing up in what 'layer' certain routines
should take place.

For instance, as you put in your example: Where would validating in the
bussiness objects stop and validating in DB objects start, or vice versa.
Are there some ground rules or methodologies for determining this in early
stages of coding a project? Do you know of some pointers; some good clear
articles perhaps?

Just out of curiousity though. I assume that you _do_ have some sort of
generic validator routines for repeating column / field validation right?
For instance a generic validateEmail() function which you call for the
specific task when doing a setEmail. You're not reinventing the wheel in
each and every getter methods right?

Thanks again!


.

Relevant Pages

  • Re: ODB (Cache?) vs ORM
    ... This is common and accepted database knowledge. ... > other way is error-prone, thus virtually guaranteed to break integrity, producing ... > is multiple orders of magnitude more powerful than procedural optimization. ...
    (comp.lang.java.databases)
  • Re: Evaluating D2005, help needed.
    ... > quality of Delphi still hasn't crossed below the productivity of Visual ... and had built several database test cases to backup your claims but now it seems ... Delphi for Win32 and VS.NET for .NET and while I'm quite confident that my ...
    (borland.public.delphi.non-technical)
  • Re: Transforming ascii file (pseduo database) into proper database
    ... contained therein so that it can be inserted into an existing database. ... So I iterate over the file maintaining a list of calls for the given phonenumber, and when the phonenumber changes, I deal with the previous cache of data, then re-initialize with the new phone's data. ... create a temp DB, skim through the file inserting all your data into a table in this DB, then use DB functionality on it ...
    (comp.lang.python)
  • Re: PHP Date Search Question
    ... > the database regardless of the date. ... You don't validate any of the above vars. ... <snip some code> ... There is a " missing in the line above. ...
    (comp.lang.php)
  • Re: Programmer knowledge
    ... > lack by comparison in power and flexibility. ... ordinary wooden toothpick to be much more powerful and flexible than MFC. ...
    (comp.programming)