My ProofOfConcept database rarely has any consistency from day to day. Usually, I throw together whatever tables I need in order to have just enough to test the exact thing I'm working on.

For example, I created table:

dbo.Hierarchy(ID int identity primary key, ParentID int references dbo.hierarchy(id1))

go

create index IDX_Hiearchy_ on dbo.hierarchy(parentid)

I then populated it with a few thousand rows of data, including some hierarchies with up to 101 levels and multiple branches.

Then I created four different procs and functions for resolving the hierarchy, including two cursors, a while loop, and a CTE.

Then I created a separate many-to-many hierarchy, to parallel corporate customers. Each company can have any number of agents, each agent can belong to any number of companies, each agent can have any number of orders. Online, the personnel assigned to a company can see the orders placed by agents who are affiliated with them, but only if the order is also associated with them, and cannot see the orders placed by agents who aren't affiliated with them or orders placed through other companies, even if the agent is also associated with them. This reflects an actual business need for two companies I've built databases for.

So I threw test tables into ProofOfConcept, with nothing more than single-column primary keys and FKs, a few indexes where the tables had more than one column, and then built a variety of procs to test performance and execution plans using various CTEs, loops, complex joins, table variables, temp tables, etc. I load up the tables and run them in dozens of different ways.

The whole point is to test completely in isolation from anything other than the exact problem I'm currently tackling. I can keep a dozen copies of a proc, put in all kinds of comments about testing, run profiles in complete isolation from anything other than the actual test at hand, etc. That's also why I run it on an isolated, low-end computer, so the results aren't polluted. It's just scientific method (controls and variables) applied to SQL.

So, yeah, I could provide you with a create script (current one is attached, if you want it), but I don't know that it'll do you much good as it currently exists.

I don't know that I've read about using this exact concept, but I'm pretty sure I didn't invent it myself and that plenty of other DBAs have the same (or similar enough) systems they use for isolated testing.