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

Am Mittwoch, 18. Juli 2001 11:31 schrieb Nils Zonneveld:
> Janning Vygen wrote:
> > But watch out the discussion "Application Design and PostgreSQL"
> > these Days in the list. I thought your way. Thought it is pretty
> > cool to have all logic inside the database, but it seems it isnt!
> >
> > How do you do your error checking?
> > You won't be vendor independent!
> > How do you check if your php sends a '1' instead of 'true' to the
> > database. I think you can only catch this error with a
> > midllerware. switching the databse is impossible.
> >
> > im just thinking about the same problem at this time and i am
> > convinced by others to put the business logic in the middleware
> > and just use SQL to store simple tables.
>
> Putting business logic in the database doesn't mean you don't have
> to check for bussiness rules in the middle tier.

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.

> There are a few
> things that a database can do without interference from the middle
> tier. For instance I have a database where depending which client
> orders stuff (flowers) and depending on the quantity, different
> percentages are substracted from the price. All those percentages
> and conditions are listed in tables, so PostgreSQL can handle that
> itself, you don't need a middle tier for that.

but how can i access the percentage via the middle tier. If i have a
object orientated middle tier, the percentage might be an attribute
of the class customer. So if your data model has a percentage for
each customer depending on other values, you have a non-persistent
attribute inside a persistent object.

> But integrity checks
> that raise an error need to be handled in the middle tier.
> On first  sight that looks like more work to be done in the middle
tier. On
> second sight though, its a guarantee that it doesn't matter if you
> have 23 different middle ware programs or just one large one, your
> data integrity will always be upheld by the database itself. That
> doesn't mean you don't have to handle those exceptions in the
> middle tier however.

To me it looks like that there are two good solutions.

first: build _ALL_ business logic inside the database. then you wont
need a middleware or just modules which are wrappers around the
backend (ex. $person = new Person(name, surname, adress) will become
insert into person values(name, surname, adress))
disadvantage: vendor specific, not easy to implement
advantage:

second: put all business logic inside the middleware.
disadvantage: every access must use this middleware.
advantage: no vendor specific code, easier to implement business
logic in your favorite programming language than in plpgsql. most
programmin languages have a lot more features and can interact with
the system(like sending mails, bills etc)

third: all logic inside database AND middleware
disadvantages: maintainance is very difficult, everything have to be
implemented twice. vendor-specific

At first glance i thought that solution one would be fine when i
first read about all postgresql features, but then i was convinced by
others in this list, that it is not a good choice.

further ideas very welcome :-)

janning

--
Planwerk 6 /websolutions
Herzogstra�e 86
40215 D�sseldorf

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