Re: Big Picture

Hi,
I think the definitions you describe below for application vs. business
logic are maybe not quite rigourous enough for me to try and use in the
workplace. But I am a database guy, I confess I like the idea of rules in
the db. However there are always trade-offs.

My general thinking is that one fundamental concept of RDBMS is data
_independance_ from applications (if I understand Dr. Codd correctly). This
faciliates the _same_ data to be used effectively and safely by many
different applications over the lifetime of the enterprise. So if
additional code in the database reduces the effectiveness with which data
can be shared among different applications in the enterprise, at that point
I would advocate for that code to be somewhere else (assuming that code
doesn't risk "nonsense" data).

Also certain rules will tend to have high liklihood of change over the
lifetime of an enterprise, and certain rules are extremely unlikely to ever
change. That is another criteria I use for the decision. I do not like the
idea of having to change the most critical code in the enterprise any more
than is absolutely neccesary. Ask the business people, domain experts, or
stake-holders- "will this rule ever change?" and "what is the likelihood
that the rule will ever change?" The answers to those questions would
provide clues where the code should live. If it is likely to change, I would
think it should not be in the DB...

Ken Ambrose

-----Original Message-----
From: pgsql-novice-owner(at)postgresql(dot)org
[mailto:pgsql-novice-owner(at)postgresql(dot)org]On Behalf Of Mark Wilson
Sent: Tuesday, October 22, 2002 2:44 PM
To: pgsql-novice(at)postgresql(dot)org
Subject: Re: [NOVICE] 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
>
>

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

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