Question

Possible Duplicate:
is there an advantage to varchar(500) over varchar(8000)?

In SQL Server we can specify the field type varchar(n):

Storage size is the actual length in bytes of the data entered, not n
bytes.

Often when planning a database structure I try to imagine the maximum possible length of strings which are to be stored in these varchar fields and then set that imagined size + some backup for the varchar field. Sometimes it may occur that the initially provided room is not enough for the field and then I need to increase the length.

But actually, is it worth limiting the varchar field to some value and not just set something like varchar(5000) or even varchar(max) which will 100% suit the case? Is there any advantage maybe in page organization in SQL Server or index organization when I limit that n length?

Update

Here is what I mean (the advantage): https://stackoverflow.com/a/5353196/355264

Yes, the query optimizer can guess how many rows fit in a page, if you
have a lot of varchar fields that are larger than necessary, SQL
Server can internally guess the wrong number of rows.

Is the above true? And are there any other advantages?

Answer 1

For one thing – you CANNOT index any column that’s over 900 bytes in size.

That alone (to me) is a killer criteria against using varchar(5000) (or varchar(max)) all the time, even if not needed….

Use the appropriate size.

Also: varchar adds at least 2 bytes of overhead, so for strings of 10 characters or less, I would always recommend using char(n) instead.

char(5) will use 5 bytes of storage – always. varchar(5) uses between 2 and 7 bytes of storage.