Question

The Overview:

I have a table “category” that is for the most part used to categorise products and currently looks like this:

CREATE TABLE [dbo].[Category]
( 
CategoryId int IDENTITY(1,1) NOT NULL, 
CategoryNode hierarchyid NOT NULL UNIQUE,
CategoryString AS CategoryNode.ToString() PERSISTED,
CategoryLevel AS CategoryNode.GetLevel() PERSISTED,
CategoryTitle varchar(50) NOT NULL,
IsActive bit NOT NULL DEFAULT 1
)

This table is heavily queried to display the category hierarchy on a shopping website (typically every page view) and can have a substantial number of items.

I’m using the Entity Framework in my data layer.

The Question:

I have a need to add what could potentially be a fairly large “description” which could come in the form of the entire contents of a web-page and I’m wondering whether I should store this in a related table rather than adding it to the existing category table given that the entity framework will drag the “description” column out of the database 100% of the time when 99.5% of the time I’ll only want the CategoryTitle and CategoryId.

Typically I wouldn’t worry about the overhead of the Entity Framework, but in the case I think it might be important to take it into consideration. I could work around this with a view or a complex type from a stored proc, but this means a lot of refactoring that I’d prefer to avoid.

I’m just interested to know if anyone has any thoughts, suggestions or a desire to slap my wrists in relation to this scenario…

EDIT:

I should add that the reason I’m hesitating to set up a secondary table is because I don’t like the idea of adding an additional table that has a 1 to 1 relationship with the Category table – it seems somewhat pointless. But I’m also not a DBA so I’m not sure whether this is an acceptable practice or not.

Answer 1

I would store in a different table for the simple reason to not increase the size of a record in Category table. An increase in record size due to such a VARCHAR column will reduce the number of records that can fit a given disk page (typically of size 4KB), thereby increasing the number of pages to fetch to main memory to search, increasing the number of disk accesses, affecting the query execution times.

I would store this in a different table (i.e. vertically partition the category table into most frequently accessed columns and not-so-frequently used columns), and define a OneToOne relationship at the application layer with the entity that contains the not-so-frequently used column, as a member in the main Category entity, set the fetch type to LAZY.