Thoughts on "createdByUserLogin" field taking id-vlong (String VARCHAR(255))

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

Thoughts on "createdByUserLogin" field taking id-vlong (String VARCHAR(255))

Ashish Vijaywargiya-5
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
Reply | Threaded
Open this post in threaded view
|

Re: Thoughts on "createdByUserLogin" field taking id-vlong (String VARCHAR(255))

Andrew Zeneski-2
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
>

Reply | Threaded
Open this post in threaded view
|

Re: Thoughts on "createdByUserLogin" field taking id-vlong (String VARCHAR(255))

Ashish Vijaywargiya-5
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
Reply | Threaded
Open this post in threaded view
|

Re: Thoughts on "createdByUserLogin" field taking id-vlong (String VARCHAR(255))

Jacques Le Roux
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
>>>
>>
>

Reply | Threaded
Open this post in threaded view
|

Re: Thoughts on "createdByUserLogin" field taking id-vlong (String VARCHAR(255))

David E Jones-3

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
>>>>
>>>
>>
>

Reply | Threaded
Open this post in threaded view
|

Re: Thoughts on "createdByUserLogin" field taking id-vlong (String VARCHAR(255))

Ashish Vijaywargiya-5
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
Reply | Threaded
Open this post in threaded view
|

Re: Thoughts on "createdByUserLogin" field taking id-vlong (String VARCHAR(255))

Adrian Crum
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
>>
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Thoughts on "createdByUserLogin" field taking id-vlong (String VARCHAR(255))

Adrian Crum
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
Reply | Threaded
Open this post in threaded view
|

Re: Thoughts on "createdByUserLogin" field taking id-vlong (String VARCHAR(255))

Jacques Le Roux
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
>

Reply | Threaded
Open this post in threaded view
|

Re: Thoughts on "createdByUserLogin" field taking id-vlong (String VARCHAR(255))

Adrian Crum
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
>>
>
>