In the past, I was part of a
project focused on redesigning core business functionality. My approach was influenced
by fundamental theory. I ended up redesigning the underlying complex database
into third normal form. It had 40 tables. When I presented this to the team,
the reaction was mixed. From surprise to frustration, I heard that 40 tables are
way too much and we need simpler and scalable design.
In following months, another team
approached this problem from fundamentally different manner more focused on code
first approach. This team initially produced key-value based database with 20
tables. This solution was finalized for implementation.
Now we are close to the implementation
and over last few months, the team working on this project had to add lot of
additional tables to address functional and non-functional requirements.
Finally, this data model is ready with 51 tables. Lot of core features like data validation and
integrity are bolted on to the initial model.
Point of this post is not to turn
this into A Vs B design discussion, but to highlight the fact that proven
design principals and practical theory like relational algebra; category theory
etc. saves lot of implementation headaches and eliminates / minimizes
complexity. In my opinion, quite often this
proven strategy is neglected for short term gains, inter/intra team dynamics or
just lack of respect for theory. What
you think? What is your experience?
