[Dbix-class] DBIx::Class as an Object-Relational mapper

[Darren Duncan]

At 13:57 -0800 15/3/06, <techwiseman-perlml at yahoo.com> wrote:
>  Well, like I said, I have been researching the issue and feel I can 
>identify with both sides of the issue. My acedemic background (and 
>most of my work experience) is OOP, so I am rather biased in that 
>direction, but I have been around DBs and DBAs and heavy DB users 
>enough to see the relational side of the arguments also.  While it 
>puts me off a bit to look at an OO system as a second-class citizen, 
>I can see how having data exposed to "user" examination/tampering 
>puts a very different spin on things.  That's not to say we can't 
>try to controt an RDBMS over an OO knee with triggers and the like, 
>to make it behave like an OO system, but I strongly agree that's 
>using the wrong tool for the job. The reasons I'm advocating 
>imposing an OO spin on the RDBMS are:
>
>  1) Our database is in some severe need of normalization anyway, and 
>imposing OO upon it will accomplish most of the important things 
>that normilization would in our case.
>
>  2) Design simplicity:  While pushing the OO concept all the way 
>back to the RDBMS will cause some headaches, I believe it will 
>prevent having to design the RDB and OO sides of the system 
>separately, and (hopefully) save ALMOST half the work.
>
>  3) (And most importantly) Selling the idea of needing two designs 
>to non-technical management appears a much more daunting task than 
>sellint the idea of a UNIFIED design.
>
>  If either of you have suggestions that address any of the above, 
>I'm most anxious to hear them.
>
>  Thank you,
>  -Loren

There's another way to look at this, which should satisfy your needs.

First of all, it is the job of a truly relational database to model 
anything in the real world accurately, and that includes everything 
that an OO language can model.

Second, a truly relational database allows its users to define custom 
data types of arbitrary complexity, so you can use an appropriate 
combination of relation definitions and custom data types to exactly 
match your OO language objects without compromise.

Third, it is the job of a truly relational database to enforce 
arbitrarily complex constraints (also known as business rules) which 
ensure the data they store is correct (as much so as you define 
correctness).  Thereby, there is no way for database users to violate 
your stored objects without editing the schema that constrains them, 
and such users can be denied such privileges.

A truly relational database includes all the features of so-called 
object-relational databases, so in fact there is no need for a 
separate o-r-d.  Databases that call themselves 'relational' but 
don't have these features are not truly relational, but only 
pseudo-relational.

So there is no reason for OO to be a second class citizen.  In fact, 
conceptually speaking, a truly relational database from the point of 
view of an application *is* a set of objects, which also happen to 
know how to make themselves persist.

A truly relational database manager is supposed to be like a 
sub-language or object class of an application language, and it is 
perfectly reasonable for the designs to be unified.

We can make it work.

-- Darren Duncan