Alexey Parshin wrote:
>The requirement to verify the stored procs integrity is very
>important. If the server doesn't support such checks - it's pretty
>difficult to enforce. Such checks normally should cut-off the
>debugging time, making some errors to popup during the procedure
>creation (instead of run-time). The alternative is - to write a
>minimal test that should run one proc or a small group of the procs
>after any changes in stored procedures. That should be doable, even if
>I didn't do that before.
Well - we'll need good test suite one way or another.
>The role in traditional databases is a set of access rights. It allows
>to work with few roles 3..15, normally, instead of people, and really
>simplifies the access maintenance. Instead of working with teachers
>John, Ben, and Alex, and admins Dick, Jane, and Bob - we just grant
>the access to DB objects to teacher and/or admin roles, and grant
>these roles to the people. If server doesn't support it, it would be a
Hold on there.. Do you suggest that we create database account
for each user? That is not going to work.
1. It is great security risk (users would actually have knowledge
of database password, which in turn can easily escalate to
2. No database will handle such number of users well
3. It will make connection pooling impossible.
There are probably more reasons, but I think ones listed above
cover it pretty well.
Ilya A. Volynets-Evenbakh
Total Knowledge. CTO
Authoright © Total Knowledge: 2001-2008