>Craig is still correct ;-)
>If your estimation that it will not bite you later holds true, that is half-ok or good enough, but you might ask yourself why you have not enough ready-2-run code for picklist use cases.
>
>>To store the emails in separate rows I would have to create a child table. This will complicate the design where it is not really necessary. These - extra emails - will be used by only a few (or just one or two) customers. So adding a child table to store the emails, IMO, is overkill. But from your words that "SQL Server will only store what it needs to" do I understand that Varchar(max) will not add more load than, say Varchar(400)?
>>
>>>SQL Server will only store what it needs to, but I question the design. Why store them all in one row instead of separate rows?
>>>
>>>>Hi,
>>>>
>>>>I need to add a column to a table that will store a string of email addresses. I am trying to decide between making this field type Varchar(SomeNumber) or Varchar(max). I expect that there will be need to store, at most, 10 email addresses in this field. So I figure that on average each email will take 40 characters and 400 will give me enough length to store 10 emails. Another approach is to make this field Varchar(max) which, I understand, will give me pretty much unlimited length. But I am concerned that Varchar(max) adds some load to the SQL Server database or SQL Server itself and leaning towards just Varchar(number). Is my concern of Varchar(max) valid? Or what would you do?
>>>>
>>>>TIA


>>These - extra emails - will be used by only a few (or just one or two) customers. So adding a child table to store the emails, In my opinion, is overkill.

Dimitry. I'm older than dirt and if there's one thing I've learned it's that for every system that died from overkill,
a hundred died from underkill.
It was almost predictable that every time I said what you said above, I had to come back and do it right.
I'd definitely normalize those addresses.