How would you do this?

Question

Post reply

How would you do this?

sumlin

Old Hand

Points: 353
More actions
December 4, 2003 at 3:41 pm

#82882

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

Viewing 5 posts - 1 through 4 (of 4 total)

You must be logged in to reply to this topic. Login to reply

David Burrows SSC Guru Points: 65142 More actions · Answer 1

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.

gljjr SSChampion Points: 10080 More actions · Answer 2

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.

sumlin Old Hand Points: 353 More actions · Answer 3

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

sumlin Old Hand Points: 353 More actions · Answer 4

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