How to build database to support user-specified entities and attributes?

From: Kunle Odutola <noemails_at_replyToTheGroup.nospam.org>
Date: Thu, 17 Mar 2005 15:55:34 +0000 (UTC)
Message-ID: <d1c99m$3kv$1@sparta.btinternet.com>

I have a database that tracks players for children's sports clubs. I have included representative DDL for this database at the end of this post.

A single instance of this database supports multiple clubs. I would like to add support for letting each club define and store custom information about arbitrary entities. Basically, allows the clubs to define custom entities (i.e tables) and associated custom attributes (i.e. fields) that may be related to existing tables (such as Player and FootballClub) or existing entities. For instance, a club may define a PlayerAssessment entity that records all player assessments.

To do this, I plan to support the following use case: 1. FootballClub admin creates a new entity and gives it a name and description (Entity is only accessible to this FootballClub). 2. FootballClub admin indicates that the new entity has a M:1 relationship with the Player table (this will add Player_ID as a FK attribute).

• {An entity may have no relationships.}
• {Relationships are also supported to other entities.} 3. FootballClub admin specifies the names and domain/types of any data attributes (i.e. fields) of the entity.
• {An attribute's type may be constrained to a few allowable types like Relationship, Integer, Float, Currency, Date, Time, DateTime, Name, Description and Memo.} 4. System creates entity as specified.

A few constraints:
1. Any entity defined is "private" to the defining club. Other clubs aren't aware of it although they may define custom entities of their own with the same name and attributes. [Perhaps there is a way to share definitions of identical entities?]
2. A club doesn't have to define any custom entities.

Ideas I've considered:
1. Generate DLL and create actual tables
- Restrict such customizations such that while admin is setting up entities,
no other user is allowed to use the system.
- Once entity definition is complete, generate an actual table using DLL.
Table and column names might be changed to enforce uniqueness/validity constraints - this suggests a need for table/column name mapping.
- PROS: Easy to implement.

• CONS: Doesn't scale since only a limited number of tables can be created. DDL on a live, shared system?. Scary!! All users for all clubs will be locked out while entity is created. 2. Generate DDL and create actual tables in secondary database(s)
• Same as above except that the user tables are created in secondary [, shared] databases.
• PROS: Reassurance that DDL is never run on the "core" data All users don't have to be locked out.
• CONS: Doesn't scale since only a limited number of tables can be created. { Unless I start creating additional databases too!. } Still needs to DDL on a live, shared system.

Has anyone done anything similar?. Any ideas on how it might be done?.

In particular, is this possible without having to execute DDL on the live database?

Kunle

• BEGIN DDL =================== CREATE TABLE FootballClub ( Club_ID int IDENTITY, Name char(80) NOT NULL, Area char(4) NOT NULL, League char(4) NOT NULL, City char(30) NOT NULL, PRIMARY KEY (Club_ID) ) go

exec sp_primarykey FootballClub,

       Club_ID
go

CREATE TABLE Player (

       Player_ID            int IDENTITY,
       First_Name           char(30) NOT NULL,
       Initials             char(30) NULL,
       Last_Name            char(30) NOT NULL,
       Date_Of_Birth        datetime NOT NULL,
       Position             char(4) NULL,
       Club_ID              int NULL,
       PRIMARY KEY (Player_ID),
       FOREIGN KEY (Club_ID)
                             REFERENCES FootballClub

)
go

exec sp_primarykey Player,

       Player_ID
go

CREATE TABLE UserAccount (

       User_ID              int IDENTITY,
       Club_ID              int NOT NULL,
       FullName             char(80) NOT NULL,
       Logon                char(20) NOT NULL,
       PWD_Hash             char(60) NOT NULL,
       PRIMARY KEY (User_ID, Club_ID),
       FOREIGN KEY (Club_ID)
                             REFERENCES FootballClub

)
go

exec sp_primarykey UserAccount,

       User_ID,
       Club_ID

go

exec sp_foreignkey Player, FootballClub,

       Club_ID
go

exec sp_foreignkey UserAccount, FootballClub,

       Club_ID
go

=================== END DDL ===================

Received on Thu Mar 17 2005 - 09:55:34 CST