If this is something you are planning to do regularly (i.e. it is part of the application logic and not a one-off data transformation exercise) then you could use a view onto Table1 and Table2 with an INSTEAD OF INSERT
trigger to manage splitting the data (and arranging the keys/relationships) - then you would just do:
INSERT newView SELECT NEWID(), A, B, C, D, E, F FROM MyTable
and the trigger could be as simple as:
CREATE trg_newview_insert TRIGGER newView INSTEAD OF UPDATE AS
INSERT table1 SELECT ID, A, B, C FROM inserted
INSERT table2 SELECT ID, D, E, F FROM inserted
GO
assuming the view is something like:
CREATE VIEW newView AS
SELECT table1.ID, A, B, C, D, E, F
FROM table1
JOIN table2 ON table1.ID = table2.ID;
or if there might be rows in each table without matching rows in the other:
CREATE VIEW newView AS
SELECT ISNULL(table1.ID, table2.ID), A, B, C, D, E, F
FROM table1
FULL OUTER JOIN table2 ON table1.ID = table2.ID;
(of course what rows are output when you SELECT
from the view is unimportant if you don't intend to SELECT
from it and it only exists to provide a template to INSERT
into for the trigger to do its magic)
This is assuming that you are intending to use a UUID type for your primary key in this case - if you are using an automatically incrementing integer key on table1 there is a little more work to do. Something like the following might work:
CREATE trg_newview_insert TRIGGER newView INSTEAD OF UPDATE AS
INSERT table1 (A, B, C)
SELECT A, B, C
FROM inserted;
INSERT table2 (ID, D, E, F)
SELECT ID, D, E, F
FROM table1 AS t
JOIN inserted AS i ON t.A = i.A AND t.B = i.B AND t.C = i.C;
GO
and in fact that pair of INSERT
statements might work directly as a one-off like so (whether you are using an INT IDENTITY
or UNIQUEIDENTIFIER DEFAULT NEWID()
type for the key):
INSERT table1 (A, B, C)
SELECT A, B, C
FROM MyTable;
INSERT table2 (ID, D, E, F)
SELECT ID, D, E, F
FROM table1 AS t
JOIN MyTable AS i ON t.A = i.A AND t.B = i.B AND t.C = i.C;
negating the need for the view and trigger completely, though if this is an operation you will be performing often in your code the view+trigger would still be worth considering to abstract out the need for multiple statements each time.
CAVEAT: all the above SQL has been typed from thought and not tested, it will need work before there is any guarantee it will work as you need.