Other Software > Developer's Corner

Programming 101 Lesson: Don't Purge User Data

<< < (5/5)

tinjaw:
OGroeger, I am going to have to disagree with you. If you are using it as a key, it should be unique. Regardless if it is a user name or a ISBN. Detach the key that identifies a *record* in a database from the *data* it holds, even if that "data" is used as a "key" is some other system. I explain this as the "Not My Database" problem. By using ISBNs you are relying on somebody else's key system to identify entities. This also locks you into using ISBNs. Use a layer of abstraction. If the people who dictate what an ISBN "is" in general, and what a specific ISBN "equates" to, then you are hosed. You are, in effect, tying your database schema to some other's schema. Primary keys are cheap.

Now, I am not advocating over normalizing your database to absurdum, but Best Practices in object oriented programming and frameworks have shown the value of adding reasonable layers of abstraction. What may seem set in stone today will seem like warm gelatin when somebody decides to change the rules without your consent.

Renegade:
Very interesting discussion here, and on one of my favorite topics - databases! :D

I'm going to have to go with the "archive the data" thing. There's no excuse for deleting users from a database. That only means that you hired a shitty consulting firm to do an inadequate job when designing the system.

Like above - "Primary keys are cheap." Agreed 100%.

It's not hard to go an extra step in normalization to use a single table as a "key" table to store only the most essential data for a particular user. e.g. Primary key, full name, passport number & type as foreign key (int), or whatever. Your table is the really nice and lean and easily searched. Getting too big? Hardly possible anymore with the current state of hardware.

Concurrency issues? Just a bad design. Primary keys should only ever be in one place, so looking in multiple places just doesn't make sense. If you're spinning things off into another database for archived data, then there's a design issue there that needs to be resolved, but still there should be no issues with duplicate information.

Ok - I'm a bit radical with database design. I like pushing towards the 5th normal form as much as possible. Data should always be unique where possible.

Ah well - I'll go back to lurking. :)

Navigation

[0] Message Index

[*] Previous page