SQL MOVE Records to another table - sql

Question

I have a number of functions which MOVE records from one table to another (generally for a form of archiving the data) and wondered if there was a "best practice" for doing this, or a more efficient method than I am currently using.
At the moment, I am running something like:
INSERT INTO archive_table
SELECT [ROWID], [COL1], [COL2]
FROM live_table
WHERE <criteria>
DELETE FROM live_table
WHERE [ROWID] IN
(
SELECT [ROWID] FROM archive_table
)
This is also throwing up a warning on the SQL performance software that the query may cause index suppression and performance degradation; due to a SCAN being performed, rather than a SEEK.
Worth adding that the archive_table is an exact copy of the live_table, with the exception that we have removed the identity and primary key off of the [ROWID] column and that this table is not used within the 'live' environment, other than having the old data inserted, as described.
[edit]
Would seem that the answer from Alex provides a really simple resolution to this; the comment about using a trigger doesn't resolve the issue in this instance as the event happens a number of days later and the criteria is dependant on events during that period.
DELETE
FROM live_table
OUTPUT DELETED.* INTO archive_table
WHERE <criteria>

Answer 1

If you have to move large number of records from one table to another, i suggest you check the possibility to partition your "active table". Each time, you copy data from one (or more) partitions to the "achieve table" and drop those partitions. It will be much faster than delete records from an "online" table.

Answer 2

Worth adding that the archive_table is an exact copy of the live_table, with the exception that we have removed the identity and primary key off of the [ROWID] column and that this table is not used within the 'live' environment, other than having the old data inserted, as described.
I can't tell if the reason you are removing the primary key from the archive_table is because you expect the ROWID's to be re-used in the live_table or not.
If I'm understanding the context of your data correctly and that you want to archive days after the data is completed, you can improve the performance of the query by reducing/eliminating the comparison of rows that will not exist in the live_table. Basically, once a ROWID has migrated from live_table to archive_table, there is no reason to look for it again.
Note: This assumes that ROWID's are not re-used in the live_table and are always increasing numbers.
INSERT INTO archive_table
SELECT [ROWID], [COL1], [COL2]
FROM live_table
WHERE <criteria>
DELETE FROM live_table
WHERE [ROWID] IN
(
SELECT [ROWID] FROM archive_table WHERE [ROWID] >= (SELECT MIN(ROWID) FROM live_table)
)
If ROWID's are re-used. If you have a datetime field in your data set that is close to when the record was live or archived it can be used as an alternative to the ROWID. This would mean you are only looking for recently archived rows to delete from the live_table, instead of the entire set. Also, making [somedate] the clustered index on the archive_table could improve performance as the data would be physically ordered to where you are only looking at the tail of the table.
INSERT INTO archive_table
SELECT [ROWID], [COL1], [COL2]
FROM live_table
WHERE <criteria>
DELETE FROM live_table
WHERE [ROWID] IN
(
SELECT [ROWID] FROM archive_table WHERE [somedate] >= DATEADD(dy,-30,GETDATE())
)

Answer 3

Your code snippet does not include a named transaction which MUST be the first consideration. Second design a table variable, temp table or hard table to use as for staging. The designed table should include a column identical in datatype to the identity column from your source table and that column should be indexed. Third design your TSQL to populate the staging table, copy rows from source table to destination table based on a join between the source and staging then remove rows from the source table based on the same join that moved data to the destination table. Below is a working sample
--test setup below
DECLARE #live_table table (rowid int identity (1,1) primary key clustered, col1 varchar(1), col2 varchar(2))
DECLARE #archive_table table (rowid int, col1 varchar(1), col2 varchar(2))
Insert #live_table (col1, col2)
Values
('a','a'),
('a','a'),
('a','a'),
('a','a'),
('b','b')
--test setup above
BEGIN Transaction MoveData
DECLARE #Staging table (ROWID int primary Key)
Insert #Staging
SELECT lt.rowid
FROM #live_table as lt
WHERE lt.col1 = 'a'
INSERT INTO #archive_table
select lt.rowid, lt.col1, lt.col2
FROM #live_table as lt
inner join #Staging as s on lt.rowid = s.ROWID
DELETE #live_table
FROM #live_table as lt
inner join #Staging as s on lt.rowid = s.ROWID
COMMIT Transaction MoveData
select * from #live_table
select * from #archive_table
select * from #Staging

Answer 4

You can use triggers for replace any CRUD Command
Add Trigger to your table for after delete operation
CREATE TRIGGER TRG_MoveToDeletedStaff ON Staff
after delete
as
DECLARE
#staffID int,
#staffTC varchar(11),
#staffName varchar(50),
#staffSurname varchar(50),
#staffbirthDate date,
#staffGSM varchar(11),
#staffstartDate date,
#staffEndDate date,
#staffCategory int,
#staffUsername varchar(20),
#staffPassword varchar(20),
#staffState int,
#staffEmail varchar(50)
set #staffEndDate=GETDATE()
SET #staffState=0
SELECT #staffID=staffID,
#staffTC=staffTC,
#staffName=staffName,
#staffSurname=staffSurname,
#staffbirthDate=staffbirthDate,
#staffGSM=staffGSM,
#staffstartDate=staffstartDate,
#staffCategory=staffCategory,
#staffUsername=staffuserName,
#staffPassword=staffPassword,
#staffEmail=staffeMail
from deleted
INSERT INTO DeletedStaff values
(
#staffID,
#staffTC,
#staffName,
#staffSurname,
#staffbirthDate,
#staffGSM,
#staffstartDate,
#staffEndDate,
#staffCategory,
#staffUsername,
#staffPassword,
#staffState,
#staffEmail
)