mysql - The Integrity of linked data entities on update -

What is the best practice for maintaining the integrity of linked data organizations on updates?

My scenario

1. I have two institutions "customer and invoice" [customer definition and invoice transaction.]
2. After issuing multiple invoices to the client, it is necessary to change the client information such as "his billing address / location change or business name ... etc".
3. It is normal that users should be able to update client information to maintain the integrity of the data in the system.
4. In Invoice "Transaction Unit" I not only know Client ID but all client information related to invoice such as "Client name, address, contact", and well known for data collection in that transaction Institutions
5. If the user has created a new invoice, the new client information will be stored in the invoice record with the same client-id (very clear!).

My question

1. Is it ok to pair data entities "clients" from different locations for updates and updates? [Explanation: If I follow the approach from step 1-4 then I will have to clamp the client unit from the client table in case of new invoices, but in case of updating / printing the invoice, I need to pair the client unit with the invoice table Otherwise the data will not be consistent or integer ... So to handle this custom requirements of data binding, without spaghetti code in the DAL, without data integrity I can keep it ??]
2. I was updating a system that was earlier versions of all versions "Keeping the history of all versions" if I use the same method to avoid custom binding How do I do this in database design using "MySQL"? [Explanation: Customer invoice was made with the version 1.0 of the customer, the customer information was updated and its version became 1.1 and new invoices made with the previous version ... So is it good to follow this method?
3. Please give me any book or reference which can kick me in the right direction?

Thank you,

What do you need to do to the table The way it is, leave it. You are right, you should store customer information in the invoice for the information where the item was sent. When this change occurs, you should not update this information except these invoices that have not yet been sent. To maintain this type of information, you need a trigger on the customer table, which takes an invoice for those that are not shipped and automatically update those addresses.

If you want to save the historical versions of client information, the correct procedure is to create an audit table and populate it through a trigger.

In this case, data integrity is only through a foreign key for the customer ID, the ID should never be allowed to be changed or changed by the user and should be an integer such as an integer number. You may not have to change address information in real invoices (unless it has been sent, in which case you change it better or the product has been sent to the wrong place), this will create data integrity. It is enough to keep it also allows you to see where the goods were actually sent but still the current information about the customer through the use of foreign keys Sees Rai.

If you have customers who change (Compass purchased by other companies), you can run a process on the server or create a table structure to update the old server's customer ID Which shows that which client ID is related to an existing parent ID, it is easy to do first if you are not talking about changing millions of records.