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 PlayerAssessmen t 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 =============== ====
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 PlayerAssessmen t 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 =============== ====
Comment