I have objects representing folders and I\'m wondering if they should be represented in the database.
On the one hand it seems like the easiest way would be to not r
First ask yourself what the purpose is of keeping the hierarchy in the database and what functionality you gain by that. Then ask consider the work and maintenance that goes into doing it.
If you're simply using it to fill a tree control, there are built-in controls that go directly against the folder system. Would that work better for you? Do you gain something beyond that by storing it in the database? How do you plan to keep the database in sync with the actual folder system, which can be changed outside of the DB? Unless your providing a virtual file system it may be better to just go directly against the real thing with relevant paths stored in the database.
SQL Server has a hierarchyid
data type that has support for hierarchical structures. Works only in the full version, mind you.
Take a look at the ERD in the middle of this page. Factoring out the hierarchy into a separate table permits you to support multiple taxonomies.
The idea is something like this (self-referencing):
CREATE TABLE FileSystemObject (
ID int not null primary key identity,
Name varchar(100) not null,
ParentID int null references FileSystemObject(ID),
constraint uk_Path UNIQUE (Name, ParentID),
IsFolder bit not null
)