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 smime.p7s (4K) Download Attachment |
I don't know about this, what if I used my (or yours for that matter)
email address as my userLoginId [hidden email] 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 > |
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 [hidden email] 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 >> > smime.p7s (4K) Download Attachment |
Administrator
|
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" <[hidden email]> > 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 [hidden email] 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 >>> >> > |
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" <[hidden email]> >> 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 [hidden email] >>> 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 >>>> >>> >> > |
I am fine with your, Andrew & Jacques thoughts on this.
Thanks & let's keep it as it is. -- Ashish David E Jones wrote: > > 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 > smime.p7s (4K) Download Attachment |
In reply to this post by Andrew Zeneski-2
I agree with you that it needs to be longer than 20 characters, and my
vote on changing it would be no also. But, I did have an issue when I first started using OFBiz because the 255 length caused index keys to exceed the maximum length allowed by my database. I changed the length to 100 on my local copy to get around the problem. Since then, my database has been improved to allow longer index keys. -Adrian Andrew Zeneski wrote: > I don't know about this, what if I used my (or yours for that matter) > email address as my userLoginId [hidden email] 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 >> > > |
In reply to this post by David E Jones-3
David E Jones wrote:
> 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. Just a little side note - the amount of space used by a VARCHAR field depends upon the hardware and OS platform. I worked on an IBM System 360 where contiguous disk space was allocated in advance for the database. The space required was calculated based on the maximum length the fields would consume, plus the maximum number of records the database would hold. In mini and mainframe computers every effort is made to allocate contiguous disk space in advance - for performance reasons. -Adrian |
Administrator
|
360! Who nowadays works still with such hardware ?
Jacques From: "Adrian Crum" <[hidden email]> > David E Jones wrote: >> 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. > > Just a little side note - the amount of space used by a VARCHAR field > depends upon the hardware and OS platform. I worked on an IBM System 360 > where contiguous disk space was allocated in advance for the database. > The space required was calculated based on the maximum length the fields > would consume, plus the maximum number of records the database would > hold. In mini and mainframe computers every effort is made to allocate > contiguous disk space in advance - for performance reasons. > > -Adrian > |
That was back in the mid 1980s.
-Adrian Jacques Le Roux wrote: > 360! Who nowadays works still with such hardware ? > > Jacques > > From: "Adrian Crum" <[hidden email]> >> David E Jones wrote: >>> 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. >> >> Just a little side note - the amount of space used by a VARCHAR field >> depends upon the hardware and OS platform. I worked on an IBM System >> 360 where contiguous disk space was allocated in advance for the >> database. The space required was calculated based on the maximum >> length the fields would consume, plus the maximum number of records >> the database would hold. In mini and mainframe computers every effort >> is made to allocate contiguous disk space in advance - for performance >> reasons. >> >> -Adrian >> > > |
Free forum by Nabble | Edit this page |