User Defined Lists Setup Alternatives

Question

I have a rather large system project coming up.  One of the pillars of this system is to have the ability for users to create generic lists that can then be referenced by the UI and backend processes.  In order to data-drive this setup, I'm searching
for different suggestions / links about setting up the tables necessary to build such a generic list setup.
As an example, a user might want to create a list containing a simple name/value pair.  Or, something more complicated where two values make up the natural key and are associated with a date value, a money value, and a couple of text values creating
a 6-column list.
I've seen a couple out there:
80/20 Rule Approach
Create a registry to store the list names and also a registry for column names and how they would be referenced / called.  The list would be stored in something like the following:
CREATE TABLE list.StandardListStore
EntryId uniqueidentifier NOT NULL DEFAULT NEWID(),
ListRegistryId uniqueidentifier NOT NULL,
KeyColumn1 nvarchar(100) NOT NULL,
KeyColumn2 nvarchar(100) NOT NULL,
KeyColumn3 nvarchar(100) NOT NULL,
TextColumn1 nvarchar(200) NULL,
TextColumn2 nvarchar(200) NULL,
TextColumn3 nvarchar(200) NULL,
FactorColumn1 decimal(15,9) NULL,
FactorColumn2 decimal(15,9) NULL,
MoneyColumn1 money NULL,
MoneyColumn2 money NULL,
DateColumn1 datetime NULL,
DateColumn2 datetime NULL,
CreateDate datetime NOT NULL DEFAULT GETDATE(),
CreateUser nvarchar(100) NOT NULL DEFAULT SYSTEM_USER,
UpdateDate datetime NOT NULL DEFAULT GETDATE(),
UpdateUser nvarchar(100) NOT NULL DEFAULT SYSTEM_USER,
CONSTRAINT PK_list_StandardListStore PRIMARY KEY CLUSTERED (EntryId),
CONSTRAINT UQ_list_StandardListStore UNIQUE(ListRegistryId, KeyColumn1, KeyColumn2, KeyColumn3)
GO
Obviously a lot of wasted space plus sooner or later, someone would want a list that wouldn't fit.  Expansion would be by adding a new datatype-based column to accommodate a larger list.
Second Approach - More Flexible but more complicated to manage
In this one you would have a trimmed down version of the list store above with just the row/entry id and key columns such as the following:
CREATE TABLE list.StandardListStore
EntryId uniqueidentifier NOT NULL DEFAULT NEWID(),
ListRegistryId uniqueidentifier NOT NULL,
KeyColumn1 nvarchar(100) NOT NULL,
KeyColumn2 nvarchar(100) NOT NULL,
KeyColumn3 nvarchar(100) NOT NULL,
CreateDate datetime NOT NULL DEFAULT GETDATE(),
CreateUser nvarchar(100) NOT NULL DEFAULT SYSTEM_USER,
UpdateDate datetime NOT NULL DEFAULT GETDATE(),
UpdateUser nvarchar(100) NOT NULL DEFAULT SYSTEM_USER,
CONSTRAINT PK_list_StandardListStore PRIMARY KEY CLUSTERED (EntryId),
CONSTRAINT UQ_list_StandardListStore UNIQUE(ListRegistryId, KeyColumn1, KeyColumn2, KeyColumn3)
GO
Then each possible datatype would have it's own dedicated table by data type such as the following:
CREATE TABLE list.StandardListTextColumns
DataId uniqueidentifier NOT NULL DEFAULT NEWID(),
EntryId uniqueidentifier NOT NULL, -- From the list store
RegistryColumnId uniqueidentifier NOT NULL, -- Column being referenced
TextColumn nvarchar(500) NULL,
CONSTRAINT PK_list_StandardListTextColumns PRIMARY KEY CLUSTERED (DataId)
GO
So, there'd be an int table, a datetime table, a money table, etc.  
This approach a lot more flexible.  The challenge here is how to combine 1-many data columns from various datatype-based column tables into some semblance of a row that can be presented to the user without hard-coding any column names (no pivot).
So, do you guys know of any books, links, samples, or have suggestions for lists such as these?  Should I install a local SharePoint instance and see how they created their user-defined list database objects?
Any advice is much appreciated.
Thanks.

Answer 1

Sounds like you're over thinking this. A list is just a list... 
Just off the top of my head, the following structure would allow a user to build whatever type of list they'd like and then be able to come back later and apply any of their lists to a given policy (for example), and store the values.
CREATE TABLE dbo.ListCategory (
ListCategoryName VARCHAR(50) NOT NULL PRIMARY KEY
CREATE TABLE dbo.ListHeader (
ListHeaderID INT NOT NULL IDENTITY(1,1) PRIMARY KEY,
ListName VARCHAR(50) NOT NULL,
ListCategory VARCHAR(50)
CONSTRAINT fk_ListCategory FOREIGN KEY REFERENCES dbo.ListCategory(ListCategoryName),
ListOwner INT
CONSTRAINT fk_Users FOREIGN KEY REFERENCES dbo.Users(UserID),
CreatedDate DATETIME
CREATE TABLE dbo.ListItems (
ListItemID INT NOT NULL IDENTITY(1,1) PRIMARY KEY,
ListHeaderID INT NOT NULL
CONSTRAINT fk_ListHeader FOREIGN KEY REFERENCES dbo.ListHeader(ListHeaderID),
ListItemName VARCHAR(100) NOT NULL,
OrderBy INT NOT NULL
CREATE TABLE dbo.PolicyListResponses (
PolicyNumber VARCHAR(50)
CONSTRAINT fk_Policy FOREIGN KEY REFERENCES dbo.Policies(PolicyNumber),
ListHeaderID INT NOT NULL
CONSTRAINT fk_ListHeader2 FOREIGN KEY REFERENCES dbo.ListHeader(ListHeaderID),
ListItemID INT NOT NULL
CONSTRAINT fk_ListItems FOREIGN KEY REFERENCES dbo.ListItems(ListItemID),
ListItemValue VARCHAR(50) NOT NULL,
CONSTRAINT pk_PolicyListResponses PRIMARY KEY (PolicyNumber,ListHeaderID,ListItemID)
HTH,
Jason
Jason Long