tags:

views:

163

answers:

4

I was wondering if it is bad practice to have a file_table { id, name, status} and a extra_data table { id, fileId FK(file.id), otherData}. So far all my tables go forward and I never needed to get the id of one table then do a query to get more data using an id.

Is this bad practice and if so then why?

+3  A: 

there is nothing wrong with this.

ctrlShiftBryan
+5  A: 

This is perfectly fine. Your table designed as laid out, establishes that one file_table record can be associated with 0 or more extra_data records. However, one extra_data record can only be associated to one file_table record.

What do you mean by going backwards?

Jose Basilio
A: 

I can't think of any other way to implement of collection of items associated with some other item. What am I missing here?

Jonathan Feinberg
+4  A: 

This is not a bad practice In fact it is how a robust design should look. Right now you established a 'relationship' with tables file and extra_data. However, in order the DB is normalized you should account the cardinality of the relationship between tables. Depending on that cardinality you will know how to place the FK or maybe you ended up creating a new relationship table. More on cardinality could be found here

Freddy
Agreed, the details are too vague to specify the required cardinality. If all columns are NULL-able then they don't even have a key!
onedaywhen