A little more explanation. Lets say you had a mailing and street address on a signup form. Would you just copy the fields via javascript and store the duplicated addresses? Or would you NULL out one of the addresses and have some field somewhere that signifies to look at the other (street) address?
The 'same_as' is kind of a smell because now I can't export that data and read it as easily, the database schema becomes more complex.
On the other hand if you just duplicate the data, the signup process is easier because you just duplicate the data, but when they update their profile you have to some how make sure edits to the mailing address also take affect to the street address (if they are supposed to be the same)
So something like
Code: Select all
if( $mailing->equals( $street ) ) // would internally compare all the strings or something.
{
... then update both identically ..
}
else
{
.. then update them independantly
}
vs having a
'same_as' column.
The first option you create a code smell, the latter is a database smell. How do you deal with this pattern? I have it happening for all sorts of concepts other then addresses. Should I treat this concept uniformly throughout the system?
Or what strategies do you use to isolate this kind of implementation detail, so it can be changed in one place later. I guess the former psuedo code may not be a smell, and may be a good way to isolate the implementation detail, but I can't quite wrap my head around how I would do it in all layers ( from javascript in the UI down to the data schema in the storage layer). I mean I've done it 100x thats no problem, but how do I avoid creating a bunch of boilerplate code?
For example I have a form that asks for each person: phone, email, address, first & last name, job title, etc...
Then we ask this information for several people:
The main contact person
The person filling out the form
The person who will be using the services,
etc...
For each of these steps they should be able to easily tell us it is the same person, and we should be able to handle the data in a professional and robust way. In the legacy system all the data was just duplicated, and updating the 'mailing address' caused the addresses to no longer be synched up ( the user would have to know he was supposed to update both addresses when it changed)