私はフォルダを表すオブジェクトを持っています。データベースに表現する必要があるかどうかは疑問です。フォルダ階層をリレーショナルデータベースに保存する
一方で、最も簡単な方法は、フォルダオブジェクトを表現せず、フォルダに含まれるオブジェクトのパス値を保存することです。私が見ている問題は、子孫がアイテムを含んでいないフォルダを永続化できないことです。また、フォルダの階層をTreeViewなどで表示する方法を明確にしておらず、すべてをメモリにロードせずに、パフォーマンス上の問題が発生する可能性があります。
代替方法として、親フォルダへの参照を含む「フォルダ」テーブルを作成する方法があります。これはうまくいくはずですが、親を共有しない限り同じ名前のフォルダを許可する方法がわかりません。それは、DBがそれ自体に関して関係するべきものであるべきか、それとも私がビジネスロジックにおいて執行すべきものなのか？
アイデアは、このようなもの（自己参照）である：
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
)
まず、階層をデータベースに保存する目的と、それによってどのような機能が得られるのかを自分自身で確認してください。次に、それを実行するための作業とメンテナンスを検討してください。
単にツリーコントロールを塗りつぶすのであれば、フォルダシステムに対して直接操作できる組み込みコントロールがあります。それはあなたのためにうまくいくでしょうか？それをデータベースに保存することで、それ以上のものは得られますか？実際のフォルダシステムとデータベースを同期させる計画はありますか？DBの外部で変更することはできますか？仮想ファイルシステムを提供しているのでなければ、データベースに格納された関連するパスを使って実際のものと直接対峙するほうが良いかもしれません。
SQL Serverには、階層構造をサポートするhierarchyidデータ型があります。フルバージョンでのみ動作します。ご心配ください。
SQL Server 2008（DB側）に提出された新しいHIERARCHYIDで実装するのは簡単です –
うーん、それはSQLCEで利用できますか？ – Davy8
@ Davy8、SQL CE以外のすべてのバージョン（Expressに含まれます）。 –