The foreign key should lead not to the entity, but to the current version of this entity

Let's say you are in charge of improving the streets. The firm "Peter and Sons" has signed an agreement with you to paint the fence at the address: Kuibyshev, Starokolpaksky perulok, 1.

At the same time, at the database level, the agreement will be linked to the address and to the company.





Five years later, Peter died. Peter's sons continue his dynasty (painting of fences).





Now the company with which the contract was signed is called "Boris and Denis". At the same time, the city of Kuibyshev began to be called Samara. Now, if you start looking for a document in order to get a tax deduction, you are unlikely to find it - your program displays that the Boris and Denis company painted a fence in the city of Samara on your instructions.





To avoid such incidents, it is necessary to store all versions of objects in the table, including obsolete ones. In terms of the address system, FIAS will help you with this, it does just that (there, each record about the address object stores the AOID identifier - this is the identifier of a specific version of the object, and the AOGUID identifier is the identifier of the address object as a whole, which does not change if the object was renamed or reassigned A similar system, I believe, exists not only for addresses, but also for properties of ever registered legal entities.





Foreign Key in Sign Language, image from corchaosis.ru
Foreign Key in Sign Language, image from corchaosis.ru

Foreign keys in your database should not lead from documents to an object, but to a specific, actual at the time of their creation, version of each object.





Otherwise, your banking system will charge customers a higher percentage, based on the fact that they do not live at the address indicated by the stamp in the passport for registration. But in reality this is the same street, it used to be called differently. And so on.








All Articles