XPost: comp.databases, comp.databases.informix, comp.databases.ingres
XPost: comp.databases.ms-access, comp.databases.ms-sqlserver, co
p.databases.postgresql.sql
XPost: comp.databases.sybase
From: nospam@nospam.nospam
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"
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 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 ===================
--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)
|
