Complex merge project...

• Jay Bee-249994

  SSCrazy

  Points: 2393

  More actions

  September 7, 2005 at 4:17 pm

  #87626

  Hi all,

  Started a new contract a few weeks ago, I've been given a daunting task - to merge the records of two Healthcare teams, the staff within the teams, their patients, and the documents for each of these patients.  The good news?  All this is in one SQL DB.  The bad news?  All this data is decentralized over various tables, and the remit is that every member of each team MUST be able to see not only his existing teams caseload, but now ALSO the caseloads of the other team.  Worst of all, the damn merger has already taken place offline.

  Now, I'm a qualified ADMIN guy...backups, performance etc are my stock in trade, but I have little to no experience of table design, and my TSQL is rusty from disuse at my last job (where I was paid truckloads just to do a 5 min daily check for nearly a year).   

  Career laments aside, I can see that Step 1 is to determine what data for each of the teams is kept where...that Step 10 is to run a merge script...but I don't know what steps 2-9 are!

  I've spent the better part of a morning ploughing through the DB diagram, and I still only have slightly better than a laymans idea of what data is stored where.  The docu isn't particularly helpful; it mainly focusses on the front end app, and the SQL Server stuff that I already had under my belt.  How would you approach this, from a project management point of view?

  Thanks in advance!

• Amit Lohia

  SSCertifiable

  Points: 6104

  More actions

  September 7, 2005 at 4:34 pm

  #588284

  Just do step 1 and step 10. You job is done

  ---

  Kindest Regards,

  Amit Lohia

• sushila

  SSC-Dedicated

  Points: 35293

  More actions

  September 7, 2005 at 9:12 pm

  #588307

  Here're are some suggestions to get you started - based on the info you've given:

  1) Start from the very top - meaning - if you're dealing with 2 healthcare teams - 2 healthcareIDs.

  2) Each of these healthcareIDs would have the staffIDs (one-to-many)

  3) Each staffID would have patientIDs (presumably one-to-many - don't know if the same patient could have 2 or more staff assigned ?!)

  4) Each patientID would have numerous documentIDs.

  Your tables then would be somewhat like this:

  tblHealthcareTeam (teamID, Description, Address ?!, Telephone ?!, Fax ?!....)

  1 - healthcareTeam1

  2 - healthcareTeam2

  tblStaff(staffID, teamID (FK), firstName, lastName, Telephone ?!....)

  1 - 1 - florence - nightingale

  tblPatient(patientID, staffID (FK), firstName, lastName, complaintDescription ?!, DateAdmitted ?!...)

  1 - 1 - wounded - soldier - bullet wound.....

  tblDocuments(docID, patientID(FK), docDate ?!....)

  not sure what tables you have already and how good the existing database design is - the best case scenario is if you can get away with this with making as few changes as possible. When I took over my present job I inherited a legacy database - I tried my best to bend over backwards and use it as it was, but all I got for my efforts was a broken back - after 6 weeks of trying to "make it work" - I tore it down and rebuilt it - it took me a 3-4 weeks to do this but was time well spent!

  if you post the DDLs of some of your major tables, I'm sure someone should be able to give you more pointers and guidelines!!!

  with all this said - is your last company looking for a replacement ?! I wouldn't mind being "paid truckloads to do a 5 min daily check..."

  
  
  
  
  
  
  **ASCII stupid question, get a stupid ANSI !!!**