Informix SQL merging/joining and updating a table - sql

Question

I have an Informix database.
EMPLOYEE
LAST_NAME FIRST_NAME SSN
----------------------------------------------
SMITH JOHN 123456789
DOE JANE 987654321
SMITH JOHN 5555555
SCHEDULE
SSN START END
---------------------------
123456789 8:00AM 4:00PM
987654321 8:00AM 4:00PM
I need to take the profile John Smith with ssn 5555555 and replace it with the other John Smith with ssn 123456789. Also with this query I need to update the Schedule table to update to with the new ssn 5555555.
The most important thing is that the profile with ssn 123456789 is now attached to the schedule table with the ssn 5555555. Then I need to be able to delete the old employee with ssn 123456789.

Answer 1

An original version of the question seemed to discuss truncating a 9-digit SSN into a 7-digit not-quite-SSN. The revised mapping of 123456789 ⟶ 5555555 is not one that can be done algorithmically. The original question also discussed dealing with multiple mappings, though the example data only shows and describes one.
I'm assuming that the Employee table does not yet have the 7-digit SSN for John Smith, even though the sample data shows that.
There are multiple ways to address the requirements. This is one way to do it.
To address the generalized mapping, we can define an appropriate temporary table and populate it with the relevant data:
CREATE TEMP TABLE SSN_map
(
SSN_9 INTEGER NOT NULL UNIQUE,
SSN_7 INTEGER NOT NULL UNIQUE
);
INSERT INTO SSN_map(SSN_9, SSN_7) VALUES(123456789, 5555555);
-- …
This table might need to be a 'regular' table if it will take time to get its content correct. This would allow multiple sessions to get the mapping done correctly.
If there is an algorithmic mapping between the 9-digit and 7-digit SSNs, you could still create the SSN_map table applying the algorithm to the SSN_9 (SSN) value to create the mapping. You might also be able to apply the algorithm 'on the fly' and avoid the mapping table, but it makes the UPDATE statement harder to get right.
Assuming the database supports transactions (Informix databases can be logged, meaning 'with transactions', or unlogged, meaning 'without transactions'), then:
BEGIN WORK;
-- Create 7-digit SSN entry corresponding to 9-digit SSN
INSERT INTO Employee(SSN, Last_Name, First_Name)
SELECT m.SSN_7, e.Last_Name, e.First_Name -- , other employee columns
FROM Employee AS e
JOIN SSN_map AS m ON e.SSN = m.SSN_9;
Some (older) versions of Informix won't let you SELECT from the table you are modifying as shown. If that's a problem, then use:
SELECT m.SSN_7, e.Last_Name, e.First_Name -- , other employee columns
FROM Employee AS e
JOIN SSN_map AS m ON e.SSN = m.SSN_9
INTO TEMP mapped_emp WITH NO LOG;
INSERT INTO Employee SELECT * FROM mapped_emp;
DROP TABLE mapped_emp;
Continuing: the Employee table now contains two entries for each mapped employee, one with the old 9-digit SSN, one with the new 7-digit not-quite-SSN.
UPDATE Schedule
SET SSN = (SELECT SSN_7 FROM SSN_map WHERE SSN_9 = SSN)
WHERE EXISTS(SELECT * FROM SSN_map WHERE SSN_9 = SSN);
This updates the Schedule with the new not-quite-SSN value. The WHERE EXISTS clause is there to ensure that only rows with an entry in the SSN mapping table are changed. If it was not present, any unmatched row would have the SSN set to NULL, which won't be good.
DELETE FROM Employee
WHERE SSN IN (SELECT SSN_9 FROM SSN_map);
COMMIT WORK;
This deletes the old data with 9-digit SSNs from the Employee table. You could drop the SSN_map table at this point too.
Complete test script
-- Outside the test, the Employee and Schedule tables would exist
-- and be fully loaded with data before running this script
BEGIN WORK;
CREATE TABLE EMPLOYEE
(
LAST_NAME CHAR(15) NOT NULL,
FIRST_NAME CHAR(15) NOT NULL,
SSN INTEGER NOT NULL PRIMARY KEY
);
INSERT INTO Employee(Last_Name, First_Name, SSN) VALUES('SMITH', 'JOHN', 123456789);
INSERT INTO Employee(Last_name, First_Name, SSN) VALUES('DOE', 'JANE', 987654321);
CREATE TABLE SCHEDULE
(
SSN INTEGER NOT NULL REFERENCES Employee,
START DATETIME HOUR TO MINUTE NOT NULL,
END DATETIME HOUR TO MINUTE NOT NULL,
PRIMARY KEY(SSN, START)
);
INSERT INTO Schedule(SSN, Start, End) VALUES(123456789, '08:00', '16:00');
INSERT INTO Schedule(SSN, Start, End) VALUES(987654321, '08:00', '16:00');
SELECT * FROM Employee;
SELECT * FROM Schedule;
-- Start the work for mapping SSN to not-quite-SSN
CREATE TEMP TABLE SSN_map
(
SSN_9 INTEGER NOT NULL UNIQUE,
SSN_7 INTEGER NOT NULL UNIQUE
);
INSERT INTO SSN_map(SSN_9, SSN_7) VALUES(123456789, 5555555);
-- In the production environment, this is where you'd start the transaction
--BEGIN WORK;
-- Create 7-digit SSN entry corresponding to 9-digit SSN
INSERT INTO Employee(SSN, Last_Name, First_Name)
SELECT m.SSN_7, e.Last_Name, e.First_Name -- , other employee columns
FROM Employee AS e
JOIN SSN_map AS m ON e.SSN = m.SSN_9;
UPDATE Schedule
SET SSN = (SELECT SSN_7 FROM SSN_map WHERE SSN_9 = SSN)
WHERE EXISTS(SELECT * FROM SSN_map WHERE SSN_9 = SSN);
DELETE FROM Employee
WHERE SSN IN (SELECT SSN_9 FROM SSN_map);
SELECT * FROM Employee;
SELECT * FROM Schedule;
-- When satisfied, you'd use COMMIT WORK instead of ROLLBACK WORK
ROLLBACK WORK;
--COMMIT WORK;
Sample output
The first four lines are the 'before' data; the last four are the 'after' data.
SMITH JOHN 123456789
DOE JANE 987654321
123456789 08:00 16:00
987654321 08:00 16:00
DOE JANE 987654321
SMITH JOHN 5555555
5555555 08:00 16:00
987654321 08:00 16:00
As you can see, the material for John Smith was updated correctly, but the material for Jane Doe was unchanged. This is correct given that there was no mapping for Jane.
For people not used to Informix: yes, you really can include DDL statements like CREATE TABLE inside a transaction, and yes, the created table really is rolled back if you roll back the transaction. Not all DBMS are as generous as that.