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

[Kunle Odutola]

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 =============== ====

[Steve Jorgensen]

First, I would limit capabilities to the following:
1. Custom player attributes.
2. Custom detail types with custom attributes.

Next, you can support multiple data types at the user interface level, but
don't try to do it with actual field types. Use 255 character text
(varchar(255) unless you're in Access).

Now, so support customization, let each club have their own label names for
each custom player attribute, and let them have their own detail type records
where each detail type defines the label names for the custom detail
attributes.

On Thu, 17 Mar 2005 15:42:28 +0000 (UTC), "Kunle Odutola"
<no******@reply ToTheGroup.nosp am.org> wrote:

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 =============== ====

[Roy Hann]

"Kunle Odutola" <no******@reply ToTheGroup.nosp am.org> wrote in message
news:d1******** **@hercules.bti nternet.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.

This is a breeze using Ingres. Create a user for each club. That user will
own the club's supplimentary tables. Create your core tables in the DBA
schema so they are visible to all users, and grant them to all relevant
users. Then allow the user who owns each club's tables to create the
supplimentary tables in their schema (this is allowed by default). That
user can then grant those tables to whichever other users he/she likes.
Because the supplimentary tables are in separate schemas for each club there
can be no naming collisions. (i.e. every club can have its own version of a
table called peanut_sales if it wants.)

Because DDL is transactional in Ingres, allowing users to create tables at
will is no less safe on a running system than any other kind of SQL.

Roy Hann (rhann at rationalcommerc e dot com)
Rational Commerce Ltd.
www.rationalcommerce.com
"Ingres development, tuning, and training experts"

[Kunle Odutola]

"Steve Jorgensen" <no****@nospam. nospam> wrote in message
news:av******** *************** *********@4ax.c om...

Hi Steve,

Please expand on your message, I'm not sure I fully understand your proposed
solution.

First, I would limit capabilities to the following:
1. Custom player attributes.
2. Custom detail types with custom attributes.
What would be the "master" of the custom detail types. Please note that the
entity may not be directly related to a player. It might be about football
boots for instance.
Now, so support customization, let each club have their own label names for each custom player attribute, and let them have their own detail type records where each detail type defines the label names for the custom detail
attributes.

I'm not sure I'm follow this bit at all. What are label names and where are
they stored?. Ditto "detail type records". How would you express the essence
of your proposal in DDL/DML?

Kunle