Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • The better DBA's I've worked with have been able to extract a healthy pile of clues from the admin tools provided with SQL Server (e.g., who has what locked).

    Since you're dealing with a single row in a single table, my number one cause of mystery grief on SQL Server--row locks getting escalated to page locks--probably isn't an issue.

    • dws wrote: The better DBA's I've worked with have been...

      Ovid replied: ha, ha, ha, grunt, snort, ha!

      We let our "DBA" go on the grounds that we couldn't afford him. That's true because while he might have been qualified to be an intern, he certainly wasn't qualified to be a senior DBA. He lied his @$$ off on his resume and when he was hired, no one was capable of evaluating his performance -- not surprising given that this company once hired a CTO who didn't know what FTP was. Then I returned to

      • by wickline (135) on 2002.10.22 15:43 (#14131) Journal
        "If you need to change it, you can just write a script to change all of the instances of it!"

        Hmmm...

        Actually, you could remove a layer of indirection by eliminating the username entirely. That way, if it changes, you don't have to update anything at all. You'll still be able to refer to users by other unique fields. The probability that any two users have the same hire date and birth date is probably sufficiently low ...and if not, you can just throw in more fields until you eliminate the duplication.

        Then you just put all those fields into each relevant table instead of the no-longer-needed username (or that stupid extra arbitrary 'id' field you keep mentioning). Huh? What do you mean "normalization"? Listen, this will work... I'm telling you.

        I guess you should probably put the username back in the table though, because we may still need to refer to it. While it may change (I guess you're right about that) so it probably won't make a good key, we should keep it around. We'll just use all these other fields as our key though.

        If you need more fields later to eliminate an unexpected future duplication, you just write a script to duplicate all those fields for all the user-related records in all the tables too. In the very unlikely event that two records can't be distinguished by using more and more fields, only then would you have to add your arbitrary 'id' field which would auto-increment as needed.

        The advantage to this approach is that if/when you ever get to the point that you have to add that extra 'id' field, you'll be able to demonstrate a dramatic decrease in database size and increase in efficiency. You see, at that point, you'll be able to use that 'id' field as the key, and re-work your tables to eliminate scores of fields. Because, you see, if you do it right, you can use just that one 'id' field instead of that big combination of fields.

        And as every certified MS professional can tell you, space savings and application speed-ups are two important ingredients in the Bonu$$ recipe.

        -matt, toungue firmly in cheek