To split a table or not to
Moderator: General Moderators
To split a table or not to
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?
- superdezign
- DevNet Master
- Posts: 4135
- Joined: Sat Jan 20, 2007 11:06 pm
Re: To split a table or not to
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".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?
Re: To split a table or not to
Califdon, Thanks a lot.. that would work perfect.
califdon wrote: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".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?