>Yes, Craig is always correct :). And trust me I know that in this particular case my approach won't bite me.
>

It probably won't but I just throw out for the sake of argument that the issue is really a mindset when designing. I assume your argument in favor of munging the emails together in one field is that it is less work.

But given that an email address is only useful if it is valid, you need to at very least use a regex validation (this is true even for the 99% that only have one address.)

Much easier to do if you know the column only holds one address.

Then there is the need to parse the column if you want to send an email to both addresses (or three or four) So now anytime you want to use the info in the email address column you have to determine how many addresses it holds and if it is necessary to parse it.

I could easily go on.

Child tables should be pretty elementary to add to a design and make so many tasks easier that I think like a lot of others here I'd really recommend normalization as just a habit of mind.

I grew up in the DBase, Foxbase, Foxpro world and I'm very familiar with the mindset that puts design second to just getting it done or being "good enough" but I grew out of it quickly when I started using SQL Server and .NET. and clients expected new requirements wouldn't break an app.

I learned long ago that doing it right is a lot less work and decoupling is a lot less brittle.

Not saying in this case you don't know the circumstances of your app better than I, but wanted to throw this perspective in the mix.