----- Original Message -----
From: "Philip Mak" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
> I've been experimenting with a programming technique idea I had that I
> call "Object Oriented Databases". The goal of the technique is to make
> programming database driven websites easier by allowing the website code
> (I use Apache::ASP, which is built on mod_perl) to access the database
> contents as objects rather than having to write SQL statements. (The SQL
> statements are in the .pm files that define the objects' methods.)
OODBMS is not a new idea; they have been around for a long time. You might
want to take a look at comp.object or comp.databases.object. However, many
people still want to use an RDBMS for storage for various reasons, but use
OO programming techniques and pretend they are dealing with an OODBMS. So,
they construct an OO<-->RDBMS mapping layer that looks like an interface to
an OODBMS, but translates that to RDBMS commands.
In another language, you might have to pay big $$ for an RDBMS<->OO mapping
layer. In Perl, however, we are lucky to have the excellent and free
Tangram. It does pretty much everything you would want an OO<-->RDBMS
mapping layer to do, except for support for changes in the object model.
You don't even have to inherit all your persistant classes from a base class
or any other similar magic.
Take a look at the Guided Tour: www.tangram-persistence.org
> One of the early problems I'm running into with this style of programming
> is that the flexibility of the MySQL queries is somewhat limited. In a
> database driven website where the relationships between the database
> tables/entities are well defined and known in advance, ad hoc queries are
> probably not needed so that the design of the *.pm files can account for
> every possible query that may need to be executed.
Building an OO::RDBMS mapping layer is a little complicated, and you are not
doing it correctly.
What you want to do is this:
* Make your object model normally, without any thought to the DBMS, so that
it is not depenant on the DBMS
* For each class, make a separate DB interface class that deals with storing
and retriving objects of that class. Make a main DB class that deals with
connecting to the database and other DB-related things.
* If you have lots of associations, it gets more complicated. You may just
want to put the association-related stuff in the main DB class, or put the
association stuff in each class that has the association, or make separate
association classes and make a DB interface for each association class.
For example, you might have something like this:
package Airplane;
sub takeoff {}
sub land {}
sub change_destination {}
package DB;
sub connect { #this would be constructor }
sub disconnect {}
sub start_transaction {}
sub finish_transaction {}
package DB::Airplane
sub insert {}
sub delete {}
sub getByAltitude {}
sub getBySpeed {}
sub getByDestination {}
sub getByAny {}
Dealing with associations and inheritance is complicated and annoying, but
can be done. If you want to roll your own, I suggest you do a search on
google for OO RDBMS mapping layer, or ask some questions in comp.object.
However, it is much easier to just use Tangram; all that suff is already
done for you. =)
> Has anyone ever done anything like this before? Do you have any comments
> about this technique?
I have been using Tangram and Template-Toolkit to develop a webapp, so far,
so good. =) The main problem is that it is a pain the the butt to have to
remake the Tangram "schema" (object model) every time I do any significant
refactoring.
-Mike
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
