Pete FreitagOn Tradeoffs
Published on November 09, 2007
By Pete Freitag
By Pete Freitag
I don't think any other kind of situation pops up more in a programmers day to day work than a Tradeoff. Tradeoffs are everywhere and being able to identify and access tradeoffs I think is one thing that makes a great developer.
Here are some places you might see tradeoffs:
- Performance Tuning - Any type of performance decision almost always involves tradeoffs. It wouldn't be tuning without some tradeoffs, else you could just press the Turbo button (remember those?).
- User Interface - There are tradeoffs involved in creating a great user interface as well. Deciding which features should be emphasized and which should be less subtle are key to creating a good interface.
- Database Design - Sure you could normalize every entity but it may take you a week to write SQL statements that join 12 tables. Likewise you don't want to waste space, and have performance issues if you don't normalize enough. You have to be able to find the sweet spot.
What tradeoffs do you face? And how do you make tradeoff decisions?
On Tradeoffs was first published on November 09, 2007.
If you like reading about tradeoffs, performance, design, or software then you might also like:
Discuss / Follow me on Twitter ↯
Tweet Follow @pfreitagComments
The down side of that approach is that you have to write more code to store the secondary addresses because the code used to store the primary address can't be reused directly, like it could with the other approach. Also if you do need to pull in all addresses primary and secondary in a particular zip, then your query just got more complicated.
But if you are doing a lot of reporting on the primary address, it might be worth the extra work to manage both address storage locations.
Tradeoffs are often very difficult decisions. You must have a deep understanding of the requirements to make a good choice. There isn't always one right answer either, so don't beat yourself up too much down the road if you realize you made the wrong decision.
But if you are doing a lot of reporting on the primary address, it might be worth the extra work to manage both address storage locations.
Tradeoffs are often very difficult decisions. You must have a deep understanding of the requirements to make a good choice. There isn't always one right answer either, so don't beat yourself up too much down the road if you realize you made the wrong decision.
by Pete Freitag on 11/09/2007 at 9:44:57 AM UTC
Off the top of my head:
Readability vs. Performance
I'll almost always opt for readability at the expense of some level of performance, but sometimes that line gets crossed and future developers will just have to suck it up.
Extensibility vs. Performance
I prefer to design for extensibility and code for performance (not my phrasing, but I can't remember where I read it). Every layer of abstraction adds some measure of overhead, but if you don't take the hit now you'll be really, really mad at yourself next year when you want to add that cool new feature that just won't fit into your monolithic architecture.
To summarize:
Now vs Later
Right now I just want it to be done and to function properly. Later, I want to be able to easily maintain it, add new features and update my business logic without a lot of redundant effort or a massive overhaul.
Readability vs. Performance
I'll almost always opt for readability at the expense of some level of performance, but sometimes that line gets crossed and future developers will just have to suck it up.
Extensibility vs. Performance
I prefer to design for extensibility and code for performance (not my phrasing, but I can't remember where I read it). Every layer of abstraction adds some measure of overhead, but if you don't take the hit now you'll be really, really mad at yourself next year when you want to add that cool new feature that just won't fit into your monolithic architecture.
To summarize:
Now vs Later
Right now I just want it to be done and to function properly. Later, I want to be able to easily maintain it, add new features and update my business logic without a lot of redundant effort or a massive overhaul.
by Rob Wilkerson on 11/09/2007 at 9:55:38 AM UTC
Thanks for the feedback. I think part of where I am coming from is an issue of poor data management. I work on some systems that have horrible data and relationships that have 1:N where N must be 1+ are not always upheld (meaning, relational constraints are not always valid). So, to deal with that frustration, I would love to have all *required* data in the same row.
But, I think if I was working with a better data set, the standard join table would be fine.
But, I think if I was working with a better data set, the standard join table would be fine.
by Ben Nadel on 11/09/2007 at 10:25:34 AM UTC
@ Ben:
just a thought - if your application allowed, as a feature, the users to select & change their primary address, including an option to select new primary address from existing secondary addresses, while saving current primary address as new secondary address...
am i making sense here? would you then store an id of an address record from Address table in a primary_address field in Contacts table?
love your KS, btw.
just a thought - if your application allowed, as a feature, the users to select & change their primary address, including an option to select new primary address from existing secondary addresses, while saving current primary address as new secondary address...
am i making sense here? would you then store an id of an address record from Address table in a primary_address field in Contacts table?
love your KS, btw.
by Azadi Saryev on 11/09/2007 at 11:33:57 PM UTC
@Azadi,
You are correct. I guess I was just reacting to a poorly thought out and maintained data set that I have to work with now. I think, had things been designed a bit better, I wouldn't even be questioning the join table, which in my gut, I know is the right way to do things.
You are correct. I guess I was just reacting to a poorly thought out and maintained data set that I have to work with now. I think, had things been designed a bit better, I wouldn't even be questioning the join table, which in my gut, I know is the right way to do things.
by Ben Nadel on 11/11/2007 at 8:44:27 AM UTC
Actually, even the Turbo button came with a tradeoff - increased power consumption and heat production.
by Brian Massey on 08/18/2009 at 2:20:57 PM UTC
But what if a contact should have a *primary* address. This is the one that will be used in all the reporting and lookups and what not. Normally, I would have some field in the Address table like is_primary.... but as of late, I am feeling like this makes things more complicated than is worth the payoff... now, I am thinking that the Address table should ONLY be for *secondary* addresses and that the COntact table itself should contain the PRIMARY address information. This way, if all you care about is primary address info (ex. get all contacts who live in zip 10011), you don't have to join tables.
Plus, there is something very nice about knowing that a primary address record always "Exists".
Thoughts?