Question : SQL 2000 Database Table Design

Hi Experts

I need some help with table design in SQL 2000. Ive attached a file showing my current layout.Ive also attached the SQL Scripts as a code snippet. The database wil record information on insurance policies and track coverage for different parties on that policy,
Ive only included the main columns in each table just to give you an idea of wat is required. The PartyRole table is Sub Typed throuout the whole database into the various roles that parties can play , its also being used to record party relationship info. The InsurancePolicyRole will track all roles on a givin insurancepolicy, this is then sub typed into InsuredParty ( Parties Insured On Policy) which in turn is sub typed into InsuredContractHolder and InsuredRelation . The CoveredParty table is a many-to-many between the Insured Parties and PolicyItems (Basically a coverage selection for each insured on the policy. According to business rules an Insurance Policy can only have one contract holder, with this model im braking this rule and cant get a way around it. Ive tried putting PartyRoleID in InsurancePolicy as a foreighn key but then i cant have that role in InsurancePolicyRole. Im not sure if im making much sense.
The business rules that i have to follow.
1 .Each Policy can have many policyItems
2. Each Policy Item can have many insuradParties and each InsuredParty can have many PolicyItems
3. Each Policy Can have ony one contract holder but many Insured Relations

I cannot change the PartyRole structure as all our application roles are Sub Typed throughout the application in other areas like payments claims events and workflow.

Any help would be appreciated Thanx.

Anthony

Code Snippet:

         
           
             1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
12:
13:
14:
15:
16:
17:
18:
19:
20:
21:
22:
23:
24:
25:
26:
27:
28:
29:
30:
31:
32:
33:
34:
35:
36:
37:
38:
39:
40:
41:
42:
43:
44:
45:
46:
47:
48:
49:
50:
51:
52:
53:
54:
55:
56:
57:
58:
59:
60:
61:
62:
63:
64:
65:
66:

           
           
             CREATE TABLE [dbo].[CoveredParty] (
	[PolicyItemID] [uniqueidentifier] NOT NULL ,
	[PartyRoleID] [uniqueidentifier] NOT NULL ,
	[TakeOnDate] [datetime] NOT NULL ,
	[InceptionDate] [datetime] NOT NULL ,
	[StatusTypeID] [uniqueidentifier] NOT NULL 
) ON [PRIMARY]
GO
 
CREATE TABLE [dbo].[InsurancePolicy] (
	[InsurancePolicyID] [uniqueidentifier] NOT NULL 
) ON [PRIMARY]
GO
 
CREATE TABLE [dbo].[InsurancePolicyRole] (
	[PartyRoleID] [uniqueidentifier] NOT NULL ,
	[InsurancePolicyID] [uniqueidentifier] NOT NULL ,
	[TakeOnDate] [datetime] NOT NULL 
) ON [PRIMARY] TEXTIMAGE_ON [PRIMARY]
GO
 
CREATE TABLE [dbo].[InsuredContractHolder] (
	[PartyRoleID] [uniqueidentifier] NOT NULL 
) ON [PRIMARY]
GO
 
CREATE TABLE [dbo].[InsuredParty] (
	[PartyRoleID] [uniqueidentifier] NOT NULL ,
	[InceptionDate] [datetime] NOT NULL ,
	[StatusTypeID] [uniqueidentifier] NOT NULL 
) ON [PRIMARY]
GO
 
CREATE TABLE [dbo].[InsuredRelation] (
	[PartyRoleID] [uniqueidentifier] NOT NULL 
) ON [PRIMARY]
GO
 
CREATE TABLE [dbo].[Organization] (
	[PartyID] [uniqueidentifier] NOT NULL 
) ON [PRIMARY]
GO
 
CREATE TABLE [dbo].[Party] (
	[PartyID] [uniqueidentifier] NOT NULL ,
	[PartyTypeID] [uniqueidentifier] NOT NULL 
) ON [PRIMARY]
GO
 
CREATE TABLE [dbo].[PartyRole] (
	[PartyRoleID] [uniqueidentifier] NOT NULL ,
	[PartyID] [uniqueidentifier] NOT NULL ,
	[RoleTypeID] [uniqueidentifier] NOT NULL 
) ON [PRIMARY]
GO
 
CREATE TABLE [dbo].[Person] (
	[PartyID] [uniqueidentifier] NOT NULL 
) ON [PRIMARY]
GO
 
CREATE TABLE [dbo].[PolicyItem] (
	[PolicyItemID] [uniqueidentifier] NOT NULL ,
	[InsurancePolicyID] [uniqueidentifier] NOT NULL 
) ON [PRIMARY]
GO

           
         

Open in New Window Select All

Answer : SQL 2000 Database Table Design

So you want to decreasing development time will decrease system performance. I stand by my assertion, change the GUID's to INT's. You might be happy with it now but it won't scale well and by then it might be too late.

I've lost count of the number of times that development thinks performance is acceptable and the users tolerate poor performance and don't complain.

As an example I worked for a company that had an online voting proxy page. No customers were complaining and usage was low (a few times per day). I had to make a change to business logic so when I mentioned to fixing some issues like this my manager shot it down with the same logic you mentioned. So I fixed it anyway because I knew I could quickly.

Lo and behold usage increased to 15 times per day and customers were complementing us on the speed increase. My manager was upset but couldn't argue with customers. As it turns out people weren't using it because it was slow and unreliable but no one bothered to complain.

Otherwise, the schema seems fine but I would make a big change to your naming convention. Prefix all primary keys with PK_ and all foreign keys with FK_

I believe that at a glance I should be able to view columns in a table and quickly determine if they have relationships with other tables.