Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 
        
Home       Members    Calendar    Who's On


Add to briefcase

How would you do this? Expand / Collapse
Author
Message
Posted Thursday, December 04, 2003 3:41 PM
Grasshopper

GrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopper

Group: General Forum Members
Last Login: Tuesday, December 09, 2003 12:00 AM
Points: 21, Visits: 1
Here's the situation:

You have a Case table (let's assume we're talking about a court case) with a CaseStatusID field. There are a dozen or so statuses that can be applied to the case before it is settled/closed. Once it is settled/closed, there are other statuses that can be applied to it. You also want to know whether the case is settled/closed or not, and when it was settled/closed.

Currently the database schema is this: (very abbreviated)
CREATE TABLE TBLCASE (
CASEID int,
CASESTATUSID int,
CASESETTLED char(1),
CASESETTLEEDATE datetime
)
CREATE TABLE LKPCASESTATUSOPEN(
ITEMID int,
ITEMVALUE varchar(50)
)
CREATE TABLE LKPCASESTATUSCLOSED(
ITEMID int,
ITEMVALUE varchar(50)
)

Some sample values in the lookup tables
INSERT INTO LKPCASESTATUSOPEN (1,'open blah')
INSERT INTO LKPCASESTATUSOPEN (1,'open yada')

INSERT INTO LKPCASESTATUSCLOSED (1,'closed blah')
INSERT INTO LKPCASESTATUSCLOSED (1,'closed yada')

The values that can go into the CASESTATUS field change depend on whether the CASESETTLED field is Y or N.

FYI, This is a database design that I have to work with, not something I created. I also know how I would solve this problem, but am looking for others ideas on how they would solve it.

I haven't mentioned the problems that I have come up with this design because I'd like to see if somebody else has any insight into the best way to accomplish the business purposes.

David




Post #18853
Posted Friday, December 05, 2003 7:25 AM


SSCertifiable

SSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiable

Group: General Forum Members
Last Login: Today @ 3:23 AM
Points: 6,795, Visits: 6,267
I would use and IF statement on CASESETTLED to decide which table to join to TBLCASE.




Far away is close at hand in the images of elsewhere.

Anon.

Post #89928
Posted Monday, December 08, 2003 7:41 PM
Mr or Mrs. 500

Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500

Group: General Forum Members
Last Login: Thursday, February 03, 2005 3:17 PM
Points: 504, Visits: 1
Are you stuck with this data model? It would seem much easier if you had a table to hold the case information (tblCase) and just one table to hold the status (tblCaseStatus). Then have a lookup table with the various valid statuses that you can set the case to (tblStatus).

You could then keep track of the changes the case goes through.

IE:

CREATE TABLE tblCase
(
iCaseID int
...
)


CREATE TABLE tblCaseStatus
(
iCaseID int
, iStatusID int
,...
, dtCreatedDate datetime default (GetDate())
)

CREATE TABLE tblStatus
(
iStatusID int
, ...
)



In this case the current status of the case would be the last record put in the tblCaseStatus table.

Gary Johnson
Microsoft Natural Language Group
DBA, Sr. DB Engineer





Gary Johnson
Microsoft Natural Language Group
DBA, Sr. DB Engineer

This posting is provided "AS IS" with no warranties, and confers no rights. The opinions expressed in this post are my own and may not reflect that of my employer.
Post #89929
Posted Monday, December 08, 2003 11:53 PM
Grasshopper

GrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopper

Group: General Forum Members
Last Login: Tuesday, December 09, 2003 12:00 AM
Points: 21, Visits: 1
Gary, interestingly enough, the application has an audit table already established with the typical fields (AuditDateTime,User,TableName,FieldName,OldValue,NewValue,etc) and as it turns out, this is one of the problems with the original design. The CaseStatusOpen & CaseStatusClosed tables each had a dozen or so entries in them, with both ID fields starting in sequential order from 1. Well, when the user Closed a Case and changed it from a status of Open with an ID of 2 to a status of Closed with an ID of 2, the audit process never entered a row into the audit table because it determined that the value never changed. What actually changed was which table it supposedly linked to because of the value of the Closed flag. I've had to write numerous queries similar to this just to show the descriptive values in the lookup tables.

FROM TBLCSCASE t
INNER JOIN (
SELECT
'Y' CLOSED,
ITEMID,
ITEMDESC
FROM LKPCASESTATUSCLOSED
UNION ALL
SELECT
'N' CLOSED,
ITEMID,
ITEMDESC
FROM LKPCASESTATUSOPEN) ls
ON t.CASESTATUSID = ls.ITEMID
AND t.CASECLOSED = ls.CLOSED


It seems to me that this join is problematic if you try to use two different tables to hold the close & open statuses, and then use the flag to determine which table should relate to the field. If you use 1 table to hold both closed & open statuses, then it seems to me that the status table should be a compound primary key consisting of StatusID & StatusClosed (or something similar). If StatusID is an IDENTITY value then you can actually use just a single join for reporting & lookups to find the descriptive value, but for referential integrity type operations (deletes,inserts,updates), you use the constraint relationship between the two fields of each table. Here's an example of what I'm thinking about created real quickly:

create table lkpcasestatus
(
casestatusid int not null identity(1,1),
casestatus char(1) not null,
casestatusdesc varchar(100) not null,
constraint pk_lkpcasestatus primary key (casestatus,casestatusid)
)
go
create table tblcase
(
caseid int not null identity(1,1),
casestatus char(1) not null,
casestatusid int not null,
casedesc varchar(100) not null,
constraint fk_tblcase foreign key (casestatus,casestatusid)
references lkpcasestatus (casestatus,casestatusid)

This seems to make it easy for reporting, (you only have to link the id field to determine the statusdesc), as well as for relational integrity, as well as making it impossible to have the same value in the table, but have it mean something else just because another field in the table changed.

Let me know what you think, maybe I'm missing something here.

David



Post #89930
Posted Tuesday, December 09, 2003 4:16 AM
Grasshopper

GrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopper

Group: General Forum Members
Last Login: Tuesday, December 09, 2003 12:00 AM
Points: 21, Visits: 1
Well, for some reason I just didn't think this one through. If I had to do this from start, the CaseClosed flag wouldn't exist in the Case table at all, it would just be an attribute in the CaseStatus lookup table.

Seems like sometimes ya can't see the forest from the trees.

David



Post #89931
« Prev Topic | Next Topic »

Add to briefcase

Permissions Expand / Collapse