Originally posted here by catch
I agree, as a rule (high assurance and very low assurance applications aside) this method of role based security is the most beneficial with the lowest cost of upkeep.
One user per application function is really just an attempt at obfuscation, a hole in your webapp isn't fixed if it ends up only being able to be done in specific areas through such restrictions. If your app needs this information, and should EVER have to update database data with your input from the web, you are just attempting to obfuscate where it can be done, and are not actually properly writing your code. Input sanitization is far and away the superior method of dealing with SQL injection problems. Multiple DB users per app is essentially a way to make your code longer while not providing any decent returns.

The issue here is if user authentication information is used to encrypt their provate data, these keys will be lost if the authentication information is reset. (Just like with EFS) resolutions for this are numerous (including my favorite, a completely seperate authenication recovery system that stores user passwords in a recoverable way and uses them to generate new passwords).
Again, doubling up on things for minimal gain. This also does not address indexing and so forth. Secure applications are worthless in the business environment if they do not perform well.

Sorry catch, considering you only really demonstrate one actual change to programming that could be beneficial, and then toss in a few concepts that may or may not be even able to be properly implemented, I'd have to give you a B for effort and about a D for implementation. There are many other things you could have covered about input sanitization (for instance, SQL-side stored procedures, PEAR:B's Prepared Statements, etc) that would help people. Perhaps you could continue this with an eye towards expanding it?