On Mon, 07 Feb 2005 10:57:57 +1100, Helen Borrie wrote:

>
>At 04:13 PM 6/02/2005 -0200, Fabricio wrote:
>
>>What is the lenght you put on DB when you add
>>a name field? I've saw that security.fdb allocates
>>3 varchar fields totalling 288 chars. Wow... It's a
>>very very long name.
>>
>>Not talking
>>of Unicode (which obviously you must double
>
>actually, unicode_fss uses 3 bytes for every character, not two.
>
>>the
>>physycal size to it store the wanted number of
>>chars) but simple varchars.
>>
>>Helen, if it is not the place to put it let me know,
>>ok? ;-)
>
>It's probably the right place, if one could just work out what the actual
>question is. Are you talking about the maximum length of object
>identifiers? That is 31 characters.

I know this (but thanks to refresh my memory - I forgot) ;-) But I feel
(IMHO) it could be 50 chars
with no problem... But it's another talk.

>Are you talking about the name parts
>in the USERS table? They are defined under the domain USER_NAME, which is
>a varchar(128). That means each name part can be a maximum of 128 ascii
>characters.

Seems I have to update to 1.5.2. Here the USERS table use a
unicode_fss varchar of 32 chars. Seems it changed to a ascii varchar
of 128.

>Are you asking how many bytes are added to security.fdb for each user added
>to it? You can calculate that yourself. Varchars are stored actual length
>+ 2 bytes. So Helen + Elizabeth + Borrie will use up 26 bytes.
>But database growth can't be predicted on the basis of the size of a
>certain field in a certain table. The engine asks for page allocations
>whenever it needs a new page. Although spare space on a page will get
>re-used if it is of a suitable size, deleting rows doesn't reduce the size
>of the database file.

The actual question is: what is the ideal space to handle a name
person? A composed varchar of 390 chars seems a little overkill...
Why that much? I never seen a name of more of 60 -75 chars (COMPLETE),
so
I double it to expect the worse: 150.