3 ms·
I used once unique many-to-many addresses by making them immutable. You don't update update them, just add new one to customer and detach old one.
by Risord 8y ago
I used once unique many-to-many addresses by making them immutable. You don't update update them, just add new one to customer and detach old one.
- pluma 8y agoSure but now you need to account for orphaned addresses. So in the scenario described you'd either end up accidentally purging the marketing addresses by cleaning up the orphans or you'd send marketing material to old addresses. That said, the story doesn't make any sense to me to begin with (privacy and junk mail concerns notwithstanding): If an address is to be shared between two people it should probably not include the recipient. But then what mailbox do you address it to if there is more than one person at the address? How do you handle business addresses (where the full shipping label may include a person, an apartment and a company)? If you keep all that info out of the "address", what is even the point of having them as separate entities? If not, how do you avoid accidentally leaking personal information if the user filled out the form incorrectly and you re-match the address to another user? If your answer is "only match if it's an exact match", how do you handle synonymous addresses (e.g. "5th Street", "Fifth Street", "5th St.")? If you treat them as distinct, why bother matching at all? Or simply: what do you gain from having addresses as separate entities (regardless of whether it's a many-to-one or many-to-many relationship with users)? If you just want to be able to say "shipping address is identical to invoice address", why not just have one or two addresses per user and never deduplicate? Have the address include the full recipient and stop trying to be clever.
- marcosdumay 8y ago> Or simply: what do you gain from having addresses as separate entities A single person has many addresses. That alone already requires the addresses to be another entity.
- Risord 8y ago> Sure but now you need to account for orphaned addresses. So in the scenario described you'd either end up accidentally purging the marketing addresses by cleaning up the orphans or you'd send marketing material to old addresses. I am not sure do I follow correctly but just send marketing to addresses which are linked to actual users. Note that some addresses are orphaned from users but not some other events like orders. > If an address is to be shared between two people it should probably not include the recipient. I don't remember details about how recipients were handled. The system was quite simple and just about business addresses. We didn't pretend that address map strictly to single physical place so synonymous addresses were considered distinct. Therefore if a recipient was part of an address that was just another distinction point. > what do you gain from having addresses as separate entities > If you just want to be able to say "shipping address is identical to invoice address", why not just have one or two addresses per user and never deduplicate? In our case customer was always company which may have quite a lot of different addresses for different offices or departments. Addresses also had hight expected reuse and we exposed saved address as a "thing" for a user so that it's easy to browse customers own orders history for different addresses etc. Uniqueness has been a quite neutral thing. Effectively it just removes case where the same customer has multiple equal addresses... Not much gain nor pain. Edit: At the end immutable shared entity is not much different from mutable and copied values. That's just one way of doing it and so far it hasn't back fired.