There are different ways to look at this.

From a database design view:
  1. If there is no strong reason, I would say always normalize your tables. Otherwise, you may not see a problem now, but big problems in the future. Believe me. The maintainance guys will blame you for the bad design.
  2. However if what you are working on is some sort of data warehouse thing, and those tables have millions of rows. Don't hesitate to denormalize your database. In this case, nobody can blame you, you are not a black sheep. Denormalization is one of the conventional ways used in data warehouse to improve performance. This is on paper.
From a OO-design view.
  1. You better have three classes defined. This is not related to the background database design, even if you decide to denormalize your tables.

    For example you denormalize those three tables in your post, and only have one asset table, you still should have three classes: asset, media, and document asset. There is no reason to break the OO rules.

    Also you will use lots more memory space, if you combine three objects into one, when you design your classes. There would be space occupied by those NULLs, BLANKs, ZEROes etc.
As a summary, don't denormalize your tables, unless you have a very good reason. If you have a very good reason, denormalization is definitely not a crime, and there are design methodologies to support you.

For your classes, always follow the rules.

Just want to add one more thing:

For database performance, join is usually not a big performance issue, although it will take some extra time. Because most of the time, join is an indexed access, not a full table scan, as long as your database is reasonably well designed, and your sql statement is carefully tuned.

In reply to Re: SQL Joins across Subclasses by pg
in thread SQL Joins across Subclasses by djantzen

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.