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 -- http://mail.python.org/mailman/listinfo/python-list
