> Ultimately, this is a tradeoff. What happens when another app wants to > use data from the same database but has less strict auth/access > requirements? So long as you know that only one application with only > one relatively-unchanging set of requirements will ever access the > database, you'll be OK, but the moment you have multiple apps, > multiple auth/access requirements or changes to the auth/access > requirements, the inflexible nature of hard-coding access at the DB > level will start causing you pain.
Access requirements, in this context, represent a relationship between the business and the data. As such, they have nothing to do with any application that's putting its own arbitrary logic in-between. > By the same argument, the organization's DBA is also outside your > control and could just as easily wreak havoc. As the old saying goes: > when you invent an idiot-proof system, the world will compensate by > producing more advanced idiots. Funny, but getting back to the argument, DBAs are not idiots. The DBA's job in the organisation is to make the database run smoothly. On May 10, 3:23 pm, "James Bennett" <[EMAIL PROTECTED]> wrote: > On 5/10/07, foobarmus <[EMAIL PROTECTED]> wrote: > > > Unfortunately, pushing access control up the stack means I > > have to rewrite all the functionality has been carefully and > > comprehensively facilitated by my RDBMS. Also it means that access > > control logic has to be written into every app that connects to the > > database - instead of just having it in the database itself. > > Ultimately, this is a tradeoff. What happens when another app wants to > use data from the same database but has less strict auth/access > requirements? So long as you know that only one application with only > one relatively-unchanging set of requirements will ever access the > database, you'll be OK, but the moment you have multiple apps, > multiple auth/access requirements or changes to the auth/access > requirements, the inflexible nature of hard-coding access at the DB > level will start causing you pain. > > > 2. When my app gets installed in an organisation, developers outside > > my control will be modifying and maintaining that instance. It would > > be easy for them to write an incorrect script that gave too much power > > to a user, and nothing would stop it from corrupting the database > > because of course with these "modern applications" the database > > connection is always made by a super-like-user that can do anything > > inside the application's database. > > By the same argument, the organization's DBA is also outside your > control and could just as easily wreak havoc. As the old saying goes: > when you invent an idiot-proof system, the world will compensate by > producing more advanced idiots. > > -- > "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~----------~----~----~----~------~----~------~--~---
