This post originated from an RSS feed registered with Ruby Buzz
by Daniel Berger.
Original Post: On Tables and Users
Feed Title: Testing 1,2,3...
Feed URL: http://djberg96.livejournal.com/data/rss
Feed Description: A blog on Ruby and other stuff.
One of the more enjoyable aspects of this Rails project I'm workign on is that I have absolute control over the schema. It's so rare that I have this opportunity. I'm usually forced to deal with an already existant schema. I am basing it somewhat on the old schema, but I've changed quite a few things.
Anyway, one decision I'm pleased I made was *not* creating a separate password column in the User table. I made the decision early on that I would use LDAP authentication. I did this for a few reasons:
* Managers often don't remember to tell the app managers that so-and-so left the company, and so that user could still potentially login to the app after they've gone. In fact, user validation sweeps are one of the side jobs I have to do from time to time here at work. HR, on the other hand, is downright fanatical about removing people from LDAP once terminated.
* Users typically have to deal with many applications. What happens when they have many passwords to remember? The vast majority do one of two things - they use either their userid or LDAP password as their password because they're lazy. I'd rather they use their LDAP password, which at least has some minimal standards of difficulty.
* I don't have to deal with encrypting and decrypting password data on the fly.
* Using LDAP provides a double layer of security - they have to exist in LDAP *and* in my database.
Another issue to consider, though, is the scenario where the user hasn't left the company, but no longer needs access to the application? Do you set the password to NULL? Leave it alone? Well, I don't have a password column, so I just delete the user from the table, right? Wrong.
In my case the solution is another column called "active", which is a simple boolean column. Why have this at all? Why not just delete the user? The answer is simple - history. Users are responsible for certain events (in my case, DSLAM turnups). We can't simply eliminate the user from the table, since we need to retain who did what and when, regardless of whether they still have access to the application. It would also be a FK constraint violation.
In short, this means that a user should be (almost) never be deleted from a database. The only exception would be users who didn't have any associated events, though that would almost certainly be limited to read-only users, test users, etc.
Previous Topic
