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
---------------------------(end of broadcast)---------------------------
TIP 8: explain analyze is your friend
