One of the enduring memories from my childhood was my father bemoaning the design and build quality of contemporary objects. Whether it was the aesthetics of a newly constructed building or the durability of a recently acquired television, the song remained the same … “They don’t build ‘em like they did in my day”.
In many ways he was right, although what he meant by “my day” was never well defined. Presumably “his day” included the construction of the pyramids and the Sistine Chapel! His point, while imbued with plenty of artistic license, raises a good question; Are we less concerned with build quality today?
In exploring this question, let’s use a 2 year old cell phone as an example. If my 2 year old phone stops working, do I send it away for repair? No, I buy a new one because a) it will probably be cheaper than repairing the old one and b) the technology has improved so much that I’ll get a much better phone anyway. The manufacturers know this, so they have no real incentive to engineer products that outlast the warranty period.
In that context, when it comes to database design, there are a number of important questions we need to ask ourselves as database professionals. Firstly, how much time should we spend engineering designs that achieve maximum performance when modern hardware can easily mask the effects of poor design, and secondly, with the increasing emphasis on timely delivery of working solutions, how much time should we spend on flexible designs that cater for unknown future usage scenarios?
The answer to both of those questions is “it depends”. A purist would argue otherwise, but a pragmatic design approach suggests that we take advantage of modern hardware and spend less time wringing every last drop of performance from our designs. In a similar manner, a certain element of design flexibility can deliver future cost savings, but should not be used as a substitute for gathering business requirements at the commencement of a development project.
Flexible and high performance database designs are often the unconscious side effect of using an experienced designer, someone whose default approach to database design has been shaped over many years of experience. Those same people often cringe when they see the work of less experienced practitioners whose designs only work due to the modern hardware they run on.
In terms of design flexibility, an area I often target is the relationships between entities. For example, a classic entity relationship is between a product and a product category. There’s a number of ways of representing this relationship. We could store the category as a column within the product table, or create a separate table for categories and include a foreign key in the product table. In both cases, there are inherent design limitations here; What if we need to include subcategories, or add a product to more than one category? With a little bit more thought, we can create a many to many table between products and categories, and design a parent-child relationship within the categories table. Such a design provides a lot more flexibility, and the cost of implementing the design up front is orders of magnitude cheaper than retrofitting the design at a later point.
Performance can be seen in a similar light; the system may perform fine with the current production load, but what happens if the user base triples overnight? Depending on the application design, throwing more hardware at the problem may not be a viable solution.
While this post doesn’t provide any answers, I hope that these questions make you think about the database design process a little more deeply, and perhaps help you to build a solution that stands the test of time, and maybe even make my father stand back and admire your creation :-)
In many ways he was right, although what he meant by “my day” was never well defined. Presumably “his day” included the construction of the pyramids and the Sistine Chapel! His point, while imbued with plenty of artistic license, raises a good question; Are we less concerned with build quality today?
In exploring this question, let’s use a 2 year old cell phone as an example. If my 2 year old phone stops working, do I send it away for repair? No, I buy a new one because a) it will probably be cheaper than repairing the old one and b) the technology has improved so much that I’ll get a much better phone anyway. The manufacturers know this, so they have no real incentive to engineer products that outlast the warranty period.
In that context, when it comes to database design, there are a number of important questions we need to ask ourselves as database professionals. Firstly, how much time should we spend engineering designs that achieve maximum performance when modern hardware can easily mask the effects of poor design, and secondly, with the increasing emphasis on timely delivery of working solutions, how much time should we spend on flexible designs that cater for unknown future usage scenarios?
The answer to both of those questions is “it depends”. A purist would argue otherwise, but a pragmatic design approach suggests that we take advantage of modern hardware and spend less time wringing every last drop of performance from our designs. In a similar manner, a certain element of design flexibility can deliver future cost savings, but should not be used as a substitute for gathering business requirements at the commencement of a development project.
Flexible and high performance database designs are often the unconscious side effect of using an experienced designer, someone whose default approach to database design has been shaped over many years of experience. Those same people often cringe when they see the work of less experienced practitioners whose designs only work due to the modern hardware they run on.
In terms of design flexibility, an area I often target is the relationships between entities. For example, a classic entity relationship is between a product and a product category. There’s a number of ways of representing this relationship. We could store the category as a column within the product table, or create a separate table for categories and include a foreign key in the product table. In both cases, there are inherent design limitations here; What if we need to include subcategories, or add a product to more than one category? With a little bit more thought, we can create a many to many table between products and categories, and design a parent-child relationship within the categories table. Such a design provides a lot more flexibility, and the cost of implementing the design up front is orders of magnitude cheaper than retrofitting the design at a later point.
Performance can be seen in a similar light; the system may perform fine with the current production load, but what happens if the user base triples overnight? Depending on the application design, throwing more hardware at the problem may not be a viable solution.
While this post doesn’t provide any answers, I hope that these questions make you think about the database design process a little more deeply, and perhaps help you to build a solution that stands the test of time, and maybe even make my father stand back and admire your creation :-)
Cheers
Subscribe to this blog!
Comments