From: "Bryan Olson" <[EMAIL PROTECTED]>
| 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 -- http://mail.python.org/mailman/listinfo/python-list
