View Single Post
Old 12-06-2012, 09:39 PM   PM User | #10
Fou-Lu
God Emperor


 
Fou-Lu's Avatar
 
Join Date: Sep 2002
Location: Saskatoon, Saskatchewan
Posts: 15,648
Thanks: 4
Thanked 2,450 Times in 2,419 Posts
Fou-Lu is a name known to allFou-Lu is a name known to allFou-Lu is a name known to allFou-Lu is a name known to allFou-Lu is a name known to allFou-Lu is a name known to all
This is completely different than a table with contact information. Each property is fully dependent on the record in order to create it in its entirety. If I have a first and last name column, two people can have the name Jane Doe, but these are distinct entities. If Jane Doe #1 marries and changes their name to Jane Smith, this doesn't alter the record for Jane Doe #2.
In this situation if you alter primary record image to change the filepath, every record changes as the image data is related via primary key. There is no comparison between the two. If you wanted to follow suit with the concept of the user table, than each image associated in slide would be an image of its own, and file1 would not be the same as file1.
If you see null entries, then it will likely violate normal form (can't recall if its 3rd or Boyce-Codd it will violate; I'm thinking 3rd, but null alone doesn't dictate this). Does that mean you cannot violate them? No, it doesn't, but it may not be wise. One of the very few exceptions I have done in the past is allowing a home and work number in a single contact table. If no home number is provided, it will be left null. Done proper I would only have a record in a ContactPhoneNumber for the associated type which I would make an enum.
You should avoid violating normalization when it comes to many to many relationships. Failing to do so creates anomalies and forces complex querying.

To do as you have and query everything at once, you would require a join on every field. That also means that if you want to cut down on the querytime you will need to index every one of them as well. See my query above for the first three columns, you simply need to expand that to cover every one. So with the unnormalized data you will have to choose to either query and end up with 15 joins, or you have to use 16 queries.

Multiple inserts are a simple matter of adding a comma in the values section: VALUES (1), (2), (3), etc. Updates and Deletes don't make any sense in this regard as you update/delete based on a where clause.
Fou-Lu is offline   Reply With Quote
Users who have thanked Fou-Lu for this post:
rgEffects (12-07-2012)