Local - Address Theory

At some future point, the theory below would also apply to Web APIs

An address is a separate and stand alone entity in SIMS referring to usually some bricks and mortar at a known position on the planet.  People then 'live' at that 'address' for a period of time and at some point in time will move to a different address or sadly pass on.  The address however is usually invariant over generations unless the plot is split or combined.  Some addresses may change their 'name' over time for example when Wooton Basset was given royal status and became Royal Wooton Basset or 'Boring Street' in Liverpool is renamed to 'Mo Salah Drive' in honour of a local celebrity.

Whilst it is possible to edit addresses in SIMS, care needs to be taken to make the correct change.  The following are the main scenarios. Let us assume that we are editing 'Bob' who lives at 1 Boring St, Liverpool. 

These scenarios may not be exhaustive but explore some valid scenarios which give the flavour of the coding challenge that managing addresses presents.

1. The address details are change for some reason.  In this case to 'Mo Salah Drive'.

  a. Bob has not moved.

  b. Bob's address record should be changed to reflect the change in street name.

  c. Anyone who lives with Bob would also have their address changed to 'Mo Salah Drive'.

  d. At some point, everyone else with an address in Boring St would need to have their addresses updated in a similar way.

2. Bob's address needs to be corrected from 1 Boring Drive to 'Sleepy Hollow, Boring Drive' and replace the house number with a name.

  a. Bob has not moved. 

  b. Is there an existing 'Sleepy Hollow' address.

      i.  If there is a 'Sleepy Hollow' address record, we should move Bob to it.

      ii.  If there is no 'Sleepy Hollow' address and Bob is the only person at that address then we could edit the address record like the example above.

      ii. If there is no 'Sleepy Hollow' address and anyone else lives at the address then we should create a new address record and move Bob to it.

  c. Anyone else at the address is unaffected but user intervention would be needed before you could move other residents to 'Sleepy Hollow'.

  d.  Address history will be created if Bob has a different address record. 

3. Bob moves house to 'Sleepy Hollow' Arcadia Avenue Everton.

  a. Bob has moved. The existing record should remain and form part of Bob's address history. 

  b. Is there an existing 'Sleepy Hollow' address.

      i.  If there is a 'Sleepy Hollow' address record, we should move Bob to it.

      ii.  If there is no 'Sleepy Hollow' address then we should create one.

  c. Anyone else at the address is unaffected but user intervention would be needed before you could move other residents to 'Sleepy Hollow'. Bob's partner for example should probably also be moved but this is 'probable' and not definite without user input.

4. Bob is deleted (GDPR / Data retention)

  a.  Bob's record is removed.

  b.  Bob's links to addresses are removed.

  c.  The address records remain (and may have other residents).

5. Bob leaves and stays at the same address.

  a.  Bob's address record is retained. 

  b.  Bob's history of addresses is retained.

6. Bob leaves and moves to a new town to live.

[First move Bob and then make him leave - thereafter]

  a.  Bob's address record is retained. 

  b.  Bob's history of addresses is retained.

Simply editing an address without context will likely corrupt data for other residents at the address.  The test required is:  'Is it possible that this edit makes a change to someone that is external to the TI's system?' If the answer is yes then it is probably wrong unless user intervention is part of the process.