Working with SQL Server 2008 R2.
I have a table of hierarchical data, with self-referencing IDs and ParentIDs. The table has about 50 fields and 50,000 records. The hierarchy goes down to about 10 levels of data. In common at each level of the hierarchy are the ID, ParentID, Title (and about 20 other fields). Here’s the critical thing: At only two levels of the hierarchy, extra fields are needed. At one level there are about 10 nvarchar(4000) fields, unique to this level. At another, the leaf, there are about 15 nvarchar(255) fields.
Should I have one table for all the common fields, e.g., ID, ParentID, Title, etc., and then secondary 1-to-1 tables for fields that only related to certain hierarchy levels?
It sure is easier to maintain if it is all in one table. But I don’t want to go too far with my development if I’m making a major database design foobar.
Kevin
This looks like Single Table Inheritance. It is my personal favorite for mapping object hierarchies in a database model, and from what you describe, should be perfectly okay for you as well. Just make sure you have a discriminator column to know which level of hierarchy you are at (equivalent to “actual type of object” for mapping objects in STI).