On Thu, 2006-08-17 at 11:43 -0500, Jim C. Nasby wrote: > Rather than create an entire extra server, why not use stored > procedures? If every access method to the database is a stored > procedure, you can remove all access to the base tables. That means that > the stored procedures can then do whatever security checking is desired; > perhaps passing each one a username and password, or an authentication > token. The procedures would then limit access to only that user's > information. > > Of course, this doesn't mean that the system is hack-proof, but there's > a number of ways to greatly improve security without resorting to one > database per user.
It will be a real mess, even if the team figures out how to implement cross-db procedures, or if the effort will be doubled/tripled for every backend, you have no stored procedures in sqlite AFAIK, then Postgres and Mysql see different what a procedure is allowed do, just look at the differences between mysql 4 and 5 regarding triggers and procedures. I agree that this way the security is better, IMO apart stored procedures there is only one addition that can be introduced, and it is encrypting of the content using username/password pair. But since the todays topic is performance, I believe such encryption is not an option. ---------------------------------------------------- Michael Tabolsky Independent IT Professional Public key: http://www.gfdsa.org/[EMAIL PROTECTED] Cassanese 200/M,Segrate (MI),20090,Italy mobile: +39 346 222 35 47 mtabolsky @ gmail...com skype: mtabolsky, JID: [EMAIL PROTECTED], icq: 919349
signature.asc
Description: This is a digitally signed message part
