Re: Big Picture

The business model that we use is based on N-tier architecture, where you
have the following levels:
User Interface - Buttons on screen etc.
Application Logic - What site navigation etc.
Business Logic - core logic. E.g. running a report
Persistence - storing data

Now, persistence really has to be in the database. Traditionally, both
business logic and application logic are mixed together and carried out in
the application layer (php).

However, we prefer to separate business logic and application logic, and put
business logic in the database. This cannot be done with MySQL of course,
but is possible with PostGreSQL. Basically, you create an API where the
application layer can only access the database via the defined views and
stored procedures (functions in Postgres).

Does this make sense?

----- Original Message -----
From: "ken" <kenzo(at)kennethambrose(dot)com>
To: "Erik Price" <erikprice(at)mac(dot)com>; <pgsql-novice(at)postgresql(dot)org>
Sent: Wednesday, October 23, 2002 6:58 AM
Subject: Re: [NOVICE] Big Picture

> Hi,
> This question has come up in so many projects I have worked on. Here is
the
> overly-simplified rule I offer at the start of the decision-making
process:
>
> If a violation of the "rule" would result in nonsense data, the rule
should
> be in the db, therefore no rogue application code can ever violate the
ruls.
>
> If a violation of the "rule" would not result in nonsense data, simply a
> business desire that is not followed, then I recommend to put the rule in
> the middle layer.
>
> Example:
>
> Business decides not to sell guns online on Washington's birthday. This
rule
> goes outside the db. If a gun is sold in violation of the rule, the order
> still makes sense, the customer got their product and the company got
paid.
>
> Business rule says each order line item must be associated to one and only
> one order number.
> This rule goes in the db, obviously an order line without an order is
> nonsense.
>
> Admittedly this is an oversimplification, but it provides me with a very
> useful rule-of-thumb for framing the debate.
>
> Comments?
>
> Ken
>
> -----Original Message-----
> From: pgsql-novice-owner(at)postgresql(dot)org
> [mailto:pgsql-novice-owner(at)postgresql(dot)org]On Behalf Of Erik Price
> Sent: Tuesday, October 22, 2002 2:52 AM
> To: pgsql-novice(at)postgresql(dot)org
> Subject: Re: [NOVICE] Big Picture
>
>
>
> On Tuesday, October 22, 2002, at 03:08 AM, Joel Rodrigues wrote:
>
> > Or, if one were looking for childishly (in programming terms) easy,
> > instant/simultaneous web gratification, try putting as much of your
> > application logic into SQL, use Python CGI scripting, and use a web
> > browser interface. So simple.
>
> Is "putting as much of your application logic into SQL" the preferred
> way to develop DB-driven applications? I ask this because the only
> database I've used is MySQL, which I enjoyed learning about and using
> but required me to implement a lot of the DB logic in my application
> code. (It was a PHP app.) That's why I want to try PostgreSQL, to get
> more experience with writing logic into the database itself. But I was
> curious if there are any resources that discuss why this methodology is
> preferrable if indeed it is.
>
> Thanks,
>
> Erik
>
> PS: I agree that Python is a great language!
>
>
>
>
>
> --
> Erik Price (zombies roam)
>
> email: erikprice(at)mac(dot)com
> jabber: erikprice(at)jabber(dot)org
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 3: if posting/reading through Usenet, please send an appropriate
> subscribe-nomail command to majordomo(at)postgresql(dot)org so that your
> message can get through to the mailing list cleanly
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 6: Have you searched our list archives?
>
> http://archives.postgresql.org
>
>