I haven't done any database design that really matters for a few years, but I would do something very different from your idea.

Lets start with fundamental basics.

I want the design to be fairly proof against new releases of the RDBMS software, in this case SQL Server; and I want not to have it preclude the use of recently added (eight years ago?) features by using bizarre configuration. So I would change this block of code to have ON in every case where tyou have OFF.ALTER DATABASE [PhysVirtTest] SET ANSI_NULL_DEFAULT OFF

GO

ALTER DATABASE [PhysVirtTest] SET ANSI_NULLS OFF

GO

ALTER DATABASE [PhysVirtTest] SET ANSI_PADDING OFF

GO

ALTER DATABASE [PhysVirtTest] SET ANSI_WARNINGS OFF

GO

ALTER DATABASE [PhysVirtTest] SET ARITHABORT OFF

GO

ALTER DATABASE [PhysVirtTest] SET CURSOR_CLOSE_ON_COMMIT OFF

GO

ALTER DATABASE [PhysVirtTest] SET CONCAT_NULL_YIELDS_NULL OFF

GO

ALTER DATABASE [PhysVirtTest] SET NUMERIC_ROUNDABORT OFF

GO

ALTER DATABASE [PhysVirtTest] SET QUOTED_IDENTIFIER OFF

GOI'm not sure that I haven't included a single ine that could sensibly have OFF, but certainly the vast majority should have ON.

Then why are there two tables (virtual objects and physical objects) instead of one? It doesn't help at all, and it does hinder! Also, what is the attitude to NULL? It seems to me that avoiding NULL is the only imaginable reason for having two tables instead of one, but your schema has NULLs anyway. Depending on how NULL-averse you are you might have more than one table, but the extra tables over and above the basic one table would be link tables, not base object tables.

So I would end up with something like CREATE TABLE dbo.PhysorVirtEx

( ID INT IDENTITY(1,1) NOT NULL Primary key Clustered

,ParentID INT NULL REFERENCES PhysorVirtEx(ID),

,Data VARCHAR(32)

,IsVirtual BIT NOT NULL,

,CONSTRAINT CKOnePar1 CHECK (ParentID is not NULL or Isvirtual = 0)

,CONSTRAINT CKVDup1 CHECK (VirtParentID <> ID)

);As you can see, I'm not so null-averse as to be silly about it.