NYCPHP Meetup

[David Krings]

John Campbell wrote:
> On 9/28/07, Kenneth Downs <ken at secdat.com> wrote:
> 
>>   I will claim that putting security
>> directly into the database is better than any other way because it does what
>> is needed in the end with the least possible work.
> 
> I must be missing something.  Take a simple social networking
> scenario: A user can only see another user's complete profile if and
> only if they are mutual friends.  Implementing that in the tables
> would be a huge pain in the ass and incur a big performance penalty.
> Is there some super easy way to implement this that I am missing?
> 
> My problem with implementing security in the database, is that it
> forces a relationship between data elements and users, where as if you
> implement the security layer between the application and the data then
> you can write policies that are a function of the data itself.

And not only that, adding security to the database will basically put 
part of the business logic into the database, which makes it very 
difficult to abstract the db layer and be db platform independent. Not 
everyone runs MySQL or MSSQL or PostGres.
My experience is that the less you rely in logic on the db the better it 
is unless you are guranateed to have your pick in db platforms. That is 
why I do not get those who sell to unknown platform environments and jam 
pack MSSQL with stored procedures. Create a real server app - which, I 
know, has some disadvantages as well.

David