I have some experience with following scenario:
1. Pg or other RDBMS realizes data integrity and transaction isolation,
only. Potentially, only _very_ well known and oldschool rules are
implemented here, for instance user sessions, which are not strictly
related with real bussiness rules. Additionally, helper (updatable)
views and stored functions are implemented to simplify and support the
next point.
2. Something as application server realizes bussiness rules.
-These processes are fully privileged (because trusted) to perform
actions on data, but they do not use Pg-superuser account. Typically,
there are httpd daemons with mod_perl. They could recognise user
privileges and perform or refuse requested operations on data.
3. Client side realizes GUI and the user inserted data basic validation.
-Typically web browsers, not trusted.
We use this to realize light or not-heavy-weight database driven webs.
Dennis Gearon wrote:
> I'd like to get people's feelings about the topic.
>
> At one extreme is to use table locking and external language queries
> to even do referential integerity - a la Old (present?) MySQL/PHP.
> A more realistic low end is to use Postgres or something more towards
> heavy iron (if necessary) and use referential integrity, data
> integrity, check cababilities.
>
> At the other end is to only allow access to normal operation of the
> database via procedures for only predefined operations on the data,
> with different levels of authority in different scripts with different
> users.
>
> It is a lot easier to change databases is the functionality is in the
> external langauge. Both the access and the data integerity and
> business rule enforcement is a lot better with only procedure access.
>
> What's everyone's experience with these paradigms?
>
> ---------------------------(end of broadcast)---------------------------
> TIP 8: explain analyze is your friend
>