You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ofbiz.apache.org by Ashish Vijaywargiya <as...@hotwaxmedia.com> on 2009/04/22 06:19:25 UTC
Thoughts on "createdByUserLogin" field taking id-vlong (String VARCHAR(255))
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
Re: Thoughts on "createdByUserLogin" field taking id-vlong (String
VARCHAR(255))
Posted by Adrian Crum <ad...@hlmksw.com>.
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 andrew.zeneski@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
>>
>
>
Re: Thoughts on "createdByUserLogin" field taking id-vlong (String
VARCHAR(255))
Posted by Ashish Vijaywargiya <as...@hotwaxmedia.com>.
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
>
Re: Thoughts on "createdByUserLogin" field taking id-vlong (String
VARCHAR(255))
Posted by Adrian Crum <ad...@hlmksw.com>.
That was back in the mid 1980s.
-Adrian
Jacques Le Roux wrote:
> 360! Who nowadays works still with such hardware ?
>
> Jacques
>
> From: "Adrian Crum" <ad...@hlmksw.com>
>> 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
>>
>
>
Re: Thoughts on "createdByUserLogin" field taking id-vlong (String VARCHAR(255))
Posted by Jacques Le Roux <ja...@les7arts.com>.
360! Who nowadays works still with such hardware ?
Jacques
From: "Adrian Crum" <ad...@hlmksw.com>
> 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
>
Re: Thoughts on "createdByUserLogin" field taking id-vlong (String
VARCHAR(255))
Posted by Adrian Crum <ad...@hlmksw.com>.
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
Re: Thoughts on "createdByUserLogin" field taking id-vlong (String VARCHAR(255))
Posted by David E Jones <da...@hotwaxmedia.com>.
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" <as...@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.zeneski@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
>>>>
>>>
>>
>
Re: Thoughts on "createdByUserLogin" field taking id-vlong (String VARCHAR(255))
Posted by Jacques Le Roux <ja...@les7arts.com>.
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" <as...@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.zeneski@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
>>>
>>
>
Re: Thoughts on "createdByUserLogin" field taking id-vlong (String
VARCHAR(255))
Posted by Ashish Vijaywargiya <as...@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.zeneski@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
>>
>
Re: Thoughts on "createdByUserLogin" field taking id-vlong (String VARCHAR(255))
Posted by Andrew Zeneski <an...@hotwaxmedia.com>.
I don't know about this, what if I used my (or yours for that matter)
email address as my userLoginId andrew.zeneski@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
>