Modeling for Shared Address Table

3

I have 3 entities: Point, Requester and Service. Each one has its own address, but it is possible that all three have the same address.

If an entity changes its address, it should not change the address of other entities, even if they have the same address.

For example: A requester has a service for your current address. When the requester changes address, the service will still be related to the old address.

It is also possible that several Services have the same address. And if the address of a service changes, that change should not affect the address of the others.

Given the current data model (below), what would be the best strategy for avoiding duplicate data ensuring that no changes will affect the other?

    
asked by anonymous 27.04.2016 / 22:37

1 answer

1

I do not know how to reuse the existing address. My experience is that this works better on paper than in practice. But it was just a complementary comment.

What you can do is use immutability . So if you register an address that will have id . Somehow this can be used by other entities. So far I think it's ok. When you need to change from one of these entities, the application will not write to the existing row where the data was read, it will create a new row with the changed data.

Then think what happens if you have to change the address and the change has to be applied to everyone who points to this address. How to solve this? I have no idea. Will you let the user decide? It does not usually work, they always make mistakes. And if it has to change in some points, but not in others? Confused is not it?

There, it is likely to start proliferating new lines where they should not. Of course you might need it. On the other hand if an address is linked to a service, then this should never be changed. This usually occurs in invoice by force of law. If by chance the address is wrong you have to use a rectification of the address, you can not just go there and change the existing one, it is immutable.

In this case it might be interesting:

  • The address is first registered at the requestor;
  • The service is created and uses the same address ( id ) that is in the requestor's registry;
  • When the requester changes the address, it does what unchanging schema that I have spoken and creates a new address for it (changes the address in the foreign key of the requestor), but does not affect the others that are using that address; >
  • The service is prohibited from changing the address. This means that if a change needs to be a rectification or the service is actually another.

I do not quite understand the function of the point there. But if it has no relation to the others, it does not matter, I just find it strange to be in the description of the question.

Readings that may help (or complicate :)):

28.04.2016 / 02:03