Click here to monitor SSC
SQLServerCentral is supported by Redgate
 
Log in  ::  Register  ::  Not logged in
 
 
 


How would you do this?


How would you do this?

Author
Message
sumlin
sumlin
Grasshopper
Grasshopper (21 reputation)Grasshopper (21 reputation)Grasshopper (21 reputation)Grasshopper (21 reputation)Grasshopper (21 reputation)Grasshopper (21 reputation)Grasshopper (21 reputation)Grasshopper (21 reputation)

Group: General Forum Members
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



David Burrows
David Burrows
SSCertifiable
SSCertifiable (8K reputation)SSCertifiable (8K reputation)SSCertifiable (8K reputation)SSCertifiable (8K reputation)SSCertifiable (8K reputation)SSCertifiable (8K reputation)SSCertifiable (8K reputation)SSCertifiable (8K reputation)

Group: General Forum Members
Points: 7965 Visits: 9417
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
gljjr
Mr or Mrs. 500
Mr or Mrs. 500 (504 reputation)Mr or Mrs. 500 (504 reputation)Mr or Mrs. 500 (504 reputation)Mr or Mrs. 500 (504 reputation)Mr or Mrs. 500 (504 reputation)Mr or Mrs. 500 (504 reputation)Mr or Mrs. 500 (504 reputation)Mr or Mrs. 500 (504 reputation)

Group: General Forum Members
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.
sumlin
sumlin
Grasshopper
Grasshopper (21 reputation)Grasshopper (21 reputation)Grasshopper (21 reputation)Grasshopper (21 reputation)Grasshopper (21 reputation)Grasshopper (21 reputation)Grasshopper (21 reputation)Grasshopper (21 reputation)

Group: General Forum Members
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



sumlin
sumlin
Grasshopper
Grasshopper (21 reputation)Grasshopper (21 reputation)Grasshopper (21 reputation)Grasshopper (21 reputation)Grasshopper (21 reputation)Grasshopper (21 reputation)Grasshopper (21 reputation)Grasshopper (21 reputation)

Group: General Forum Members
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



Go


Permissions

You can't post new topics.
You can't post topic replies.
You can't post new polls.
You can't post replies to polls.
You can't edit your own topics.
You can't delete your own topics.
You can't edit other topics.
You can't delete other topics.
You can't edit your own posts.
You can't edit other posts.
You can't delete your own posts.
You can't delete other posts.
You can't post events.
You can't edit your own events.
You can't edit other events.
You can't delete your own events.
You can't delete other events.
You can't send private messages.
You can't send emails.
You can read topics.
You can't vote in polls.
You can't upload attachments.
You can download attachments.
You can't post HTML code.
You can't edit HTML code.
You can't post IFCode.
You can't post JavaScript.
You can post emoticons.
You can't post or upload images.

Select a forum

































































































































































SQLServerCentral


Search