1 Employee has N Address. Here I need to maintain the historical information of Employee and Address changes if any changes is done by any users in these two table.
Table Employee:
Employee(
EmpID BIGINT PRIMARY KEY IDENTITY(1,1),
Name varchar(200),
EmpNumber varchar(200),
Createddate Datetime2)
Address Table :
Address(
AddID BIGINT PRIMARY KEY IDENTITY(1,1),
AddressLine1 varchar(300),
AddressLine2 varchar(300),
EmpID BIGINT NULL,
AddressType varchar(100),
Createddate Datetime2)
Above,EmpID is a foreign Key to the Employee table
Scenario I have to satisfy :
- I should be able to track the changes of an individual address(Child table records) record of any employee.
- I should be able to track the track the changes of a Employee(Parent table records) with child address record.
I thought following way:
Suppose, Initially it is in the state shown in image below

Solution 1:
Case : when child table gets updated
Now, I update a Add0001 Address Record, So i insert a new record in address table making previous record inactive as:

Case : when Parent Table gets updated
Now, When Parent Table gets update, I have history table for the Parent Table and i am moving old data to the history table and update the current records into the parent table as shown:

Solution 2 :
Case : When child table gets updated Same as in solution 1
Case : When Parent Table gets updated
We insert a new record in the parent table making previous records inactive. In this case we get a new ID and that ID, we update as foreign key to the child tables as shown below:
Is this the best way of maintaining historical data of parent-child table together? or is there any way i can keep the design so that i should be able to track the changes altogether of parent and child records data ?

There are quite a few ways to go about this sort of thing and what you're proposing is a perfectly valid approach... At least you appear to be pointed in the right direction.
There are a couple of changes that I would suggest...
1) Get rid of the "status" flag and use "begin" and "end" dates. The specific names don't matter so long as you have them.
2) Both the begin and end date columns should be defined as "NOT NULL" and begin should have a default constraint of GETDATE() or CURRENT_TIMESTAMP. The end date should be defaulted to '99991231'. Trust me and fight the urge to make the end date NULLable and giving "active" rows NULL end dates. '99991231' is, for all practical purposes, the end of time. and can be used to to easily identify the currently active rows.
3) I would suggest adding a trigger to the following:
Hope this helps. :)