New
#31
Whenever I've done that, it always comes back and bites me in the arse.
As for storage space, it used to be a problem years ago, but technology has finally caught up in the storage arena. Our databases aren't that big at work any ways, but I can certainly understand extreme instances such as the company Visa might have.
For the primary key, meh... I never use that column of data. It's just there for the SQL server to keep track of its own thing, hehehe. I always run my own ID column to track records to know sequentially which one is in what order.
Oh, PULEEZE! You can't seriously think I was serious about that! Three tongues sticking out? A veritable list of stupid things to do? I feel insulted!
I assumed you were joking but it is honestly hard to tell. One developer I worked with swore by reusing database records as to not incur the hit of insert a new clustered index. He would instead take an inactive record and overwrite the non-index fields. He didn't keep his job long.
Myself....I'm a fan of GUID as primary keys with secondary indexed natural keys when appropiate.
I think most DB designers that have a fair understanding of the infrastructure they work in pretty much agree on common sense things. Like not use the SSN as the primary key for employee records, because typos do happen, and you can't change a PK (at least not easily).
Hey, no worries mate. You can come out of the corner .
i dont understand any of that junk
but according to PCwizard, i have a secret duel core processor, that i never knew about. and get this, it runs @ -0.999324741Mhz ... awesome?
Geek speek, nerd werds. Bit heads.
You can always tell a programmer, you just can't tell him much.