Boy, this is the first time I've ever been tempted to talk about my company here, but I will resist. Suffice to say there are many wonderful commercial tools for optimizing and benchmarking SQL and it might be very instructive to get your DBA one of them so that he can see for himself what the different forms of the queries run like compared to one another.

As for the heart of the issue, I think the one point being missed here is the age old struggle between the different camps in any IT organization. Speaking as aomeone who often has to straddle these fences, remember that when approaching these problems you need to take a look at why the DBA might be saying what he's saying. tilly says that we need to take a step back and look at this as a programming problem. While I whole-heartedly agree that gets us to the right conclusion (i.e. to normalize mercilessly), what it does not do is get you any closer to getting the DBA to do that.

I deal with a lot of DBAs, and a DBA only cares that the DB perfroms well and is up. If your code is slow b/c of structures in his DB that is not really his problem. When you suggest a large normalization effort, right or wrong, he hears things running slow in the DB and therefore him getting the short end of the stick. What you must do is to be sure and approach the problem with his concerns in mind. Don't demand or simply refer to rules and accepted policy; he doesn't care about that stuff =). Be sure to tell him that it will increase performance on the whole and therefore no one will be coming after him just b/c transactions may spend more of their time in the database side than the application side - if the overall transaction time is better no one will care! Make sure he understands that you have just as great an interest in maintaining the saner structure so that you can assist in those tasks when it's needed and that you'll help from a budget perspective if that means buying some tools to help with that (if you can). Basically, walk in his shoes for a bit, then re-approach. He is more than likely just trying to be sure he's doing his job - even if it seems he's not too aware of how it should be done.

We speak the way we breathe. --Fugazi

In reply to (jptxs)Re: Database Design Issues: on roasting DBAs by jptxs
in thread Database Design Issues - OT by Ovid

Title:
Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post, it's "PerlMonks-approved HTML":


  • Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
  • Titles consisting of a single word are discouraged, and in most cases are disallowed outright.
  • Read Where should I post X? if you're not absolutely sure you're posting in the right place.
  • Please read these before you post! —
  • Posts may use any of the Perl Monks Approved HTML tags:
    a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
  • You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)
            For:     Use:
    & &amp;
    < &lt;
    > &gt;
    [ &#91;
    ] &#93;
  • Link using PerlMonks shortcuts! What shortcuts can I use for linking?
  • See Writeup Formatting Tips and other pages linked from there for more info.