Yes, I agree... let's leave it all as-is. The number is a limit to the
size and has nothing to do with the actual amount of space required to
store the field... ie it is a VARCHAR and will only use the space
required for the length of the actual value.
Whatever the case, if it's not hurting anything, let's not change
it... especially when there may very well be systems that have values
that long so we'll need it in order to work with them.
-David
On Apr 23, 2009, at 1:00 AM, Jacques Le Roux wrote:
It don"t think we should change that. In DB only characters used are
taking place so I don't see the trouble
Jacques
From: "Ashish Vijaywargiya" <ashish.vijaywarg...@hotwaxmedia.com>
Thanks Andrew for your reply.
I agree on your point that in some companies they prefer email
address for user login.
I am fine by not changing it but instead of keeping length 255 ,
100 would be good option on data base perspective (I think :-) ).
I don't have any specific reason in my mind for this change Andrew,
lets see what other has to say.
--
Ashish
Andrew Zeneski wrote:
I don't know about this, what if I used my (or yours for that
matter) email address as my userLoginId andrew.zene...@hotwaxmedia.com
that is 31 right there. Its really tough to say how much space is
needed for such a field. 100 might be enough, but it is the change
worth it? My vote is no, but maybe you have a specific reason in
mind for the suggestion?
Andrew
On Apr 22, 2009, at 12:19 AM, Ashish Vijaywargiya wrote:
Hello,
Yesterday I was reviewing few entities, then I realized that we
are using "id-vlong" for the fields acting as foreign key &
referring to the "userLoginId" of the UserLogin table.
"id-vlong" = VARCHAR(255) is too much space for saving the
userLoginId. At max I can think of userLoginId to be of length of
25 or 30.
For ex. few reference are :
createdByUserLogin field in MarketingCampaign entity.
dontCancelSetUserLogin in OrderItem entity.
If there is any specific reason for keeping it of this much
length then please share your thoughts on this.
Thanks in Advance.
--
Ashish Vijaywargiya