On Tue, May 29, 2007 at 07:26:51PM +0200, Lukas Kahwe Smith wrote:
> Jim Nasby wrote:
>
> >>Yup, the tend to heavily rely on data integrity management on the
> >>middle tier. Which by the way is not totally crazy, because you
> >>need most of the data integrity rules on the frontend anyways, to
> >>generate proper GUI's. Actually in non object-relational RDBMS
> >>(which are the norm, PostgreSQL is special), you can never do your
> >>full integrity management inside the database.
> >
> >Can you give an example of that, because I can't think of one,
> >unless you're talking about integrity that has to lie outside the
> >database (ie: if you're storing filesystem locations in the
> >database).
>
> Yes, but more trivially since like "is this a valid email address"
This is where PostgreSQL really shines. You can create a DOMAIN
constraint that checks whether an address is valid all the way up to
checking whether it's accepted for delivery, although I'd imagine you
wouldn't want to do that last. You can then use that DOMAIN all over
your code.
> >Perhaps if you carefully hand-code your middleware... my experience
> >is that things like Hibernate tend to destroy performance because
> >unless you really, really know it well you end up with some pretty
> >bad database access methods. It doesn't have to be that way, but it
> >often is.
>
> Yeah, I think at the very least ORM's make it less obvious when you
> are calling something expensive. It all happens sort of magical and
> you do not really know when something is going to cost you and if so
> how much.
All this magic means that you're taking on a larger hassle, more
subtle bugs, etc., etc. for no long-term benefit.
Cheers,
D
--
David Fetter <david@fetter.org> http://fetter.org/
phone: +1 415 235 3778 AIM: dfetter666
Skype: davidfetter
Remember to vote!
Consider donating to PostgreSQL: http://www.postgresql.org/about/donate