Kristian Nielsen wrote:
Kay Röpke <[email protected]> writes:
the problem really comes down to:> if any part of the app needs access to certain data, certain people> will have
access to the data (because there must be some way to access> the username/password combination) otherwise it's
useless.> "certain people" depends on the size of the organization, i guess. in> my experience it means
either a) devs or b) DBAs. or both for small> companies. outside of those two groups, people don't generally have>
access to the systems (accounting, marketing or other "business"> folks).
Agree.
To me, this and similar issues like roles, foreign keys, stored procedures,etc.
etc. comes down to one thing: Do I want to develop my system in theframework of
some RDBMS or in a real programming language like Perl, Java, orwhatever the
current fashion happens to be.
To me the choice is clear. I have never seen anything from a database/RDBMSthat
I consider even remotely on the level I would expect of a goodprogramming
language. I _have_ seen disasters like tens of thousands of linesof Oracle
stored procedures implementing business logic etc. It always ends upwith one
half of the app being implemented in the database, and the other inthe
application language, which generally is terrible.
So this is what I like, and what I think MySQL (and Drizzle) is targeting,which
is probably why I like MySQL.
So by all means let us have features like foreign keys, stored procedures,
rowfilters etc. They are occasionally useful. Just do not expect me to use then
asa general replacement for a real application development framework.
But to each his own.
Isn't it better for application developers to concentrate on application
semantics and ease of use than understanding and enforcing security
policy as well, particularly given the potential ramifications of a
security breach?
Let me give you a real world example. A large law firm built an
application to manage all aspects of running a law firm -- tracking
correspondence, case management, billing, docketing, etc. Huge system.
In addition to managing all aspects of internal workings, it allowed
clients to track aspects of their cases, and was also the external Web
site for the firm. The system was implemented by two very smart guys
and a bunch of summer interns.
A major problem, however, is that a lawyer the compromises confidential
client information is subject to disbarment. Not all that many of the
hundred attorneys were happy about the idea that their license to
practice law depended on the skill and conscientiousness of some summer
interns.
This was the problem to lead to filtersets that enabled declarative
access policy to be consistently and rigorously enforced so that an
attorney could see all aspects of his or her cases, a client could see a
chosen subset of data for his (and only his) cases, and the public
couldn't see much of anything real at all.
Filtersets work with declarative per-table access policy, where the
policy is expressed as a boolean to be applied to all retrievals on that
table. Many of the booleans necessarily referenced other table (as in,
he can see this iff he can see that), so the booleans have to be applied
recursively. In one instance, a simple with table retrieval expanded to
17 page pretty print selection criterion.
I submit that a) this is beyond the skill and conscientiousness of a
summer intern, b) beyond the skills and conscientiousness of the two
very smart guys, c) subject to frequent changes that would otherwise
have required modification of thousands of lines of code, and c) had
ramifications of ending careers if breached.
This is something that databases can easily enforce that skilled
programmers can't.
_______________________________________________
Mailing list: https://launchpad.net/~drizzle-discuss
Post to : [email protected]
Unsubscribe : https://launchpad.net/~drizzle-discuss
More help : https://help.launchpad.net/ListHelp
