Change the Code : DBA/Designer always has to look out for the third dimension
Posted by carl.reitschuster on August 9th, 2006
Hi reader,
today we discussed the difference between changes in code and changes in database structure in our team. if you change the logical structure of a database as designer you always have the third dimension in your mind - the data. Structure changes very often cause data migration. And that’s the point. So the Designer is not really finished when he changed the database model.
You could say being a developer is not easy but being a Designer/DBA is a lot more complex - it’s thinking in another dimension.
Karl
August 10th, 2006 at 09:41
That’s a typical DBA point of view (just teasing ;-) ).
Just one example: Suppose I have a WebService that publishes customer data. Now the customer data structure changes (say, “I need the customers favorite color for marketing purposes!”). You (in principle) don’t know who consumes the web service. You cannot break existing consumers. What do you do?
Answer: Support both versions at the same time! I.e. the web service should detect the version the client is using in his request and also shape the response accordingly. So we have two different versions active at the same time (whereas the database is always in exactly one defined version).
Ergo: the dimensions of complexity may be different but versioning is a pain in the a**, no matter at which end of the application you work.
Just my 0,02€
August 10th, 2006 at 09:47
Thanks Alex for your update!
This shows to me in every area (not only database) you have to work with complexity due to flexiblity the customer want’s to have.
The thing with the data is that it’s frequntly ignored (who cares for data?) and then causes a lot of pain.
Karl