I wanted to poke at everyones brain to better understand when it makes sense to normalize a table that carries redundant data. I recently worked on a project at my startup and really question myself on whether it was a good idea. So the problem was something like this.
Our web app is a e-commerce web app. Our db contains a table that looks like this:
Store Product Table ----------------------- - product_name - price - store_product_id - coupon_name
The data looks something like this:
pk, product_name, price , store_product_id, coupon_name 1, 'Orange Juice', 10.0, 2, 'ORANGE15PERCENT', 2, 'Orange Juice', 10.0, 2, 'ORANGE50PERCENT', 3, 'Orange Juice', 10.0, 2, 'ORANGE70PERCENT' 4, 'Milk', 9.0, 89, 'MILK20PERCENT', 5, 'Milk', 9.0, 89, 'MILK50PERCENT' 6, 'Ham', 5.0, 45, '', ... 300, 'Jacket, 100.0, 90, 'JACK50PERCENT',
This is a relatively small table (~200 records). As you can tell there is a ton of redundancy. I saw redundancy and broke this out into two tables a
Product table and
Coupon table. This eliminated all the redundancy. I felt proud at first, but I wonder if it was really necessary. Should one always remove redundancy in a tables and break apart as two tables? Please note that this decision was made way past the initial db design phase. It's probably an easy decision to make when you are first designing things, but what about when you've built a codebase around a redundant table?
Note: I realize that there are pros to having redundant data if your table is a read heavy table, since this is a small table I don't think thats super relevant in this situation. Open to be proved wrong though.