Re: Re: PG rules! (RULES being the word ;->) - Mailing list pgsql-general

You might be interested in Alzabo (http://sourceforge.net/projects/alzabo/).
From the docs:

"Alzabo is a dual-purpose project. Its first goal is to be a data modeller,
written in Perl. Its second goal is to use the data model created as the basis
on an OO-RDBMS mapping."

I haven't used it myself, but have heard others recommend it.  It's being
actively developed.

As far as where to put business rules... you might consider putting *data
integrity* rules in the database via constraints, foreign keys, etc., while
reserving the rest of the logic for the middle tier.  And of course you don't
want your application to even try to put bad data into your database, so you'll
also wind up having checks for that in the middle tier as well.

The great thing about the advent of the Relational Database umpteen years ago is
that it makes it possible for multiple applications to share the same database.
Sticking ALL business logic in the database almost gets us back to the
monolithic mainframe apps of years ago, that had no real separation between
program and data.  Let the database protect itself against faulty data via
constraints, but keep the bulk of the logic in the middle tier (or any tier
besides the db, for purposes of this discussion).  Hope that helps.

Wes



Janning Vygen <vygen%planwerk6.de@interlock.lexmark.com> on 07/18/2001 11:00:51
AM

To:   Thomas Lockhart <lockhart%fourpalms.org@interlock.lexmark.com>
cc:   pgsql-general%postgresql.org@interlock.lexmark.com (bcc: Wesley
      Sheldahl/Lex/Lexmark)
Subject:  Re: [GENERAL] Re: PG rules! (RULES being the word ;->)


Am Mittwoch, 18. Juli 2001 16:36 schrieb Thomas Lockhart:
> > this way i have to implement my businees logic twice. inside the
> > database and in the middleware. I dont think that this is very
> > good.
>
> Hmm. Sounds like you are writing both the DB and the app. So
> enforcing *your* business rules in the DB is not so important to
> you because you are trusting yourself to do the same in the app.
> But for cases where the project outgrows one programmer, or where
> there are multiple apps touching the *same* DB, isolating the
> business rules - into the one place in common between these apps -
> becomes a more obvious choice.

What do you mean with "isolating the business rules - into the one
place in common between these apps"

what is the place _between_ these apps? Do you mean the middleware?
or do you mean, that businnes rules are at one place and are then
parsed into middleware and database from the same source?? This would
be a great tool. Do you know one?

janning

--
Planwerk 6 /websolutions
Herzogstraße 86
40215 Düsseldorf

fon 0211-6015919
fax 0211-6015917
http://www.planwerk6.de

---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?

http://www.postgresql.org/users-lounge/docs/faq.html