Page 1 of 1
To split a table or not to
Posted: Sat Feb 17, 2007 10:59 am
by GeXus
I have one table called "content" and within that there is main content and description content. Because im keeping a history of all of the content and description content with date stamps asigned to each, I will have a lot of empty columns for one or the other, meaning there will never be content and description content in the same row. Would it be benificial to split this into two tables, even though they are all somewhat related?
Posted: Sat Feb 17, 2007 11:13 am
by superdezign
I cant see anything wrong either way, but splitting it up would make it more organized if you have empty columns. Empty columns are a waste.

Re: To split a table or not to
Posted: Sat Feb 24, 2007 9:20 pm
by califdon
GeXus wrote:I have one table called "content" and within that there is main content and description content. Because im keeping a history of all of the content and description content with date stamps asigned to each, I will have a lot of empty columns for one or the other, meaning there will never be content and description content in the same row. Would it be benificial to split this into two tables, even though they are all somewhat related?
As an old database instructor, I'll say that there is one and only one criterion for what columns should be in a table:
all columns that contain attributes of the entity represented by a table. Now, what does that mean? It's hard to know whether "content" is an entity because you haven't given enough information to judge that. What does the table really represent? What distinguishes one piece of content from another? How are you going to index it? My first impression would be that content is content, and I'd suggest perhaps a single table with a single "content" column, a datestamp column, and a "type" column that could be of type
enum, having two values: either "main" or "description".
Re: To split a table or not to
Posted: Mon Feb 26, 2007 8:34 pm
by GeXus
Califdon, Thanks a lot.. that would work perfect.
califdon wrote:GeXus wrote:I have one table called "content" and within that there is main content and description content. Because im keeping a history of all of the content and description content with date stamps asigned to each, I will have a lot of empty columns for one or the other, meaning there will never be content and description content in the same row. Would it be benificial to split this into two tables, even though they are all somewhat related?
As an old database instructor, I'll say that there is one and only one criterion for what columns should be in a table:
all columns that contain attributes of the entity represented by a table. Now, what does that mean? It's hard to know whether "content" is an entity because you haven't given enough information to judge that. What does the table really represent? What distinguishes one piece of content from another? How are you going to index it? My first impression would be that content is content, and I'd suggest perhaps a single table with a single "content" column, a datestamp column, and a "type" column that could be of type
enum, having two values: either "main" or "description".