Should this be represented in the database as 1 table or 3 tables? I and my friend have different opinions about this so I\'d like to see the general views on this. (Maybe
I'm no purist, so 3nf is good when it makes sense...but you don't have to take it for granted that it always will.
From a pragmatic standpoint, what is your goal? Your pros/cons list is a good start. I'd add a few more ideas to the list -- as you see fit.
1) Will any other table in your database need to relate (e.g., join) to this data? That's kind of the point of an RDB.
2) Will your database grow? Even if 1 table makes sense now, will it always make sense? You'll regret it, if you find yourself wanting to add more tables, and your non-normalized table is forcing you to 'work-around' it, dealing with extra rows returned, slower execution times, etc.
3) What happens when your customer gets a new external account, or what have you. Will you create a brand-new record? How will you answer questions like "What is customer so-and-so's account number?".
...
I think in general, i go for scalable, which in this case may mean 3nf. 1 table is easier to deal with in a very narrow scope, but if anything ever changes, you'll be dealing with "How do I split this table into properly related 3nf tables, without messing up all of the dependencies that have been created on it?". That one is no fun.