Subject | Re: [firebird-support] What is normal space you allocate to the name of a person? |
---|---|
Author | Helen Borrie |
Post date | 2005-02-06T23:57:57Z |
At 04:13 PM 6/02/2005 -0200, Fabricio wrote:
question is. Are you talking about the maximum length of object
identifiers? That is 31 characters. 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.
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.
./hb
>What is the lenght you put on DB when you addactually, unicode_fss uses 3 bytes for every character, not two.
>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
>theIt's probably the right place, if one could just work out what the actual
>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? ;-)
question is. Are you talking about the maximum length of object
identifiers? That is 31 characters. 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.
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.
./hb