Is there an obvious way to do this in python?

[H J van Rooyen]

From: "Bryan Olson" <fakeaddress at nowhere.org>


| H J van Rooyen wrote:
| [...]
|  > This is broadly what I had in mind, yes - but sort of down to
| a transaction
|  > level - this user does invoicing, this one enters cheques,
| this one does credit
|  > notes, and their supervisor can do all three, and in a
| different department its
|  > different because the jobs are different, but the invoicing
| GUI module is the
|  > same for wherever its used...
|
| Pretty much any business has to deal with those things. You are
| right about the need for transactions and authorization, and
| that you don't want to have to manually update all the clients
| whenever your modify the applications. Everyone has those
| problems, and consequently there's a large body of experience
| and conventional best practice. The highly redundant advice
| you've been getting is recommending that you to do those things
| that way most successful modern systems do them.
|
| No question what you describe calls for a DBMS. Further, this
| sounds like a job for a "three tier" architecture, what Dennis
| L. Bieber explained as [db-server] <-> [app-server] <-> [client].
| In the old days a three-tier system called for a large
| data-processing staff; today one guy can set up a simple one in
| an afternoon.
|
| In a three-tier system, either the database, the server
| application can enforce authorization policy. In order for the
| database to enforce authorization, the application creates one
| database connection for each client user, and logs in as the
| user. That works well for most accounting-type systems, where
| all the users are known in advance. In systems such as web
| shopping carts, the application typically has its own user ID,
| and creates all database connections as itself. The app, not the
| database, is then responsible for keeping users from reading and
| altering each other's data.
|
| Trying to enforce authorization at the client is generally a
| mistake. The user has too much control over his local machine.
| He is not limited to running just the code you provide.
|
|
| Don't get too hung up on choice of DBMS, but stick with portable
| standard SQL. I bet you'll find your potential customers want it
| to run against the database they already have. The particular
| tables your system needs will become part of their larger
| schema.
|
|
| --
| --Bryan

Thank you - this is a sane summary of the general business case, and I
particularly like the bit about keeping the SQL portable - its something I did
not even consider...

The conventional best practice advice is swamping my original query of how to do
something in Python...

Just a note:

If conventional best practice is followed all the time, without question - how
is it ever made better?
but that is probably a question for a separate thread - please ignore it
here... - it has nothing to do with the Python language.

- Hendrik