views:

100

answers:

6

I have three tables: Post, Attachment, and Media.

Posts have Attachments, and Attachments have Media.

Currently, the Post and Attachment tables are linked by foreign keys, and so are the Attachment and Media tables. My question is, for the sake of proper database design and normalization, should I setup a foreign key relationship between Post and Media? I'm unsure as to how deep I should link these tables together.

Thanks

A: 

Link tables as deep as makes sense. Denormalize for reporting and after seeing performance issues.

TomTom
+1  A: 

I think that you are OK.

It seems possible that a POST can have several ATTACHMENTs and that an ATTACHMENT can have several POSTs, if so you will need a link entity for third normal form:

  Post

    |
    |
  -----
  | | |

Post_Attachment

  | | |
  -----
    | 
    |

Attachment

    |
    |
  -----
  | | |

  Media

But from your description there seems to be no key relationship between POST and MEDIA.

amelvin
+2  A: 

No, for normalization as deep as 3NF is concerned your, which is the usual normalization level, the structure is ok.

For the record normalization has it costs as well as it benefits, specially for data insertion and deletion against a major level of control over precisely how and what can be inserted.

One normalized and denormalizes at his own risk :)

Jorge Córdoba
+2  A: 

for the sake of proper database design and normalization, should I setup a foreign key relationship between Post and Media?

For "proper normalization" you have to assure that there are no "update anomalies".

If someone updates a Post, what happens to Attachments and Media? Will renaming a post disconnect the attachments and/or the media? If so then your FK is wrong. [Hint, you must use surrogate keys not the name of the post to make your FK's work.]

If someone wants to "move" an Attachment from one Post to another [i.e., update the Attachment's FK reference], what happens to the Media? Does it stay with the Attachment and move to the new Post?

Could you wind up with Post having Attachments and Media, as well as Attachments having Media? Could the Post and the Attachments disagree about the Media because the Attachment was "moved" but the Post wasn't also updated?

If you can have contradictions, you have broken 2nd Normal Form and you have repeated key relationships you should not have repeated.

Proper Normalization is easy.

Data Depends on the Key and Nothing But the Key.

Do not copy or repeat dependencies anywhere. What you're calling "deep linking" appears to be a repetition of dependencies.

S.Lott
All that whatif are bussiness logic concerns from my point of view. The underlying structure represent certain asumptions and relationships (Posts may have attachments, attachments may have media files or not). I assume that's what he has in mind and for that it is normalized.
Jorge Córdoba
Your comment regarding "moving" an Attachment from one Post to another is what brought this home to me. Thanks! (Now it's time to hit the books and fidn out what surrogate keys are ;))
Arms
@Jorge Córdoba. I think that the "business logic" is what the database must represent. I can't see how there is an "underlying structure" other than the "business logic" that must be supported.
S.Lott
+1  A: 

The only reason for adding a FK from Media to Post would be if you need to filter or select media for a particular post without regard for the attachments. Even if you need to display media (perhaps by type) and the post it belongs to, I wouldn't add a direct association; the overhead for adding a second join (via the attachment table) is likely to be minimal, so you're unlikely to see any significant improvement.

TMN
A: 

First off, you don't need to use surrogate keys. A proper database will cascade updates if you desire. When normalizing a database, you're usually trying to achieve 3rd normal form or even BCNF. 2nd normal form will not always protect your data from update anomalies. Determining the functional dependencies in your schema should be simple once you produce an ER diagram and decide what data is part of the entities (Posts, Attachments, Media) and what data is part of the relationships. Depending on the cardinality of your relations, you may or may not need join tables. The best thing to do is to model your data in a diagram, then deal with the implementation issues.

dcolish
Do use cascade update. What a horrible suggestion. Do you know the effect when you need to update 10,000 rows that have milllions of associated records? It's a database that is locked for hours that no one can use. Cascade update is poor practice.
HLGEM
Millions of associated records? Thats sounds like a terrible design. Cascade updates are perfectly reasonable. In any sane database they will not lock tables.
dcolish