The data column's meaning changes depending on the value of the type column.

One phrase that comes to mind is "job security". By constructing tricky schemas like the first one, someone makes themselves extra "useful" writing the overly complicated query code necessary to access data correctly, at least until they're taken out and shot by the people who have to maintain and extend the result.

The problem with columns that change their types or meanings depending on other columns (like the type column above) is that complexity gets pushed out in all directions. Anyone who queries the data needs to take on the complexity of deciphering the type field, plus whatever other contortions are necessary to process the data. Standard tools, and standard approaches stop working cleanly. And the more time passes, the more people forget why the poor design was chosen in the first place, which can make it harder to undo the damage.

When I see stuff like this, it's often because someone hasn't gotten over their fear of database JOINs, which can be scary until you've done them a few times. However, JOINs are an essential tool. Trying to avoid them is like being afraid to take off the training wheels on a bicycle.

In reply to Re: OT: benefits of database normalization by dws
in thread OT: benefits of database normalization by revdiablo

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.