Tim


Did I read that right - VARCHAR will preserve trailing spaces? Please tell me that's not going to happen, or if it is you're supplying a field type which will continue to trim the trailing spaces.

I hate to think of the amount of work I'll need to do if trailing spaces are preserved.


Roy Lambert

Tim,

<< No.  It will support Char and VarChar, which are implemented exactly the
same way. >>

Strange implementation IMHO. The standard is very clear about the difference
between CHAR and VARCHAR, and other database engines commonly implement it
that way.

What's the purpose of having separate CHAR and VARCHAR types if they're
implemented exactly the same way ?

Ole

Tim,

thanks.  I mixed myself up a little.  I always though VarChar2(x) would:
1) Allow storage for that field for 1 to x characters
2) Not right pad
3) Only physically take up space for that particular field row.

I.E.

VarChar2(40)

1000 records of a that field storing 40 X's, would take up less hard
drive space than the same number of records with 5 X's.

I can completely understand performance hits.

But as you say... Hard Drive space is so inexpensive at this point and
as long as you use common sense in designing your tables (I.E.
Varchar(100) for First Name, Middle Name, Last Name.  Realistically, 25
is more than ample).


Lance


Tim Young [Elevate Software] wrote:
> Lance,
>
> << is ElevateDB going to support varchar2 types (physical size 2
> bytes[length] larger than actual size) like some DB's, such as Oracle? >>
>
> No.  It will support Char and VarChar, which are implemented exactly the
> same way.  Char will not introduce space padding, contrary to the ANSI
> standard (this is legacy crap anyways - if the developer or user wants
> spaces, then they'll put them in).  However, both Char and VarChar will
> preserve leading/trailing spaces if they are in the text, unlike DBISAM.
> Also, the "NATIONAL" variations will be parsed and mapped back to the two
> types since, in the Unicode version, Char, VarChar, and their National*
> variations, will all support Unicode characters.  Likewise, the ANSI version
> of ElevateDB will not support Unicode at all.  We're looking to the future
> with this design since Unicode will be the standard character set in a
> fairly short period of time, and I didn't want to get into mixing ANSI and
> Unicode support for such a short period of time.
>

Ole,

<< Strange implementation IMHO. The standard is very clear about the
difference between CHAR and VARCHAR, and other database engines commonly
implement it that way. >>

The padding can cause some weird things to happen that might make things a
little difficult during the transition from DBISAM.

<< What's the purpose of having separate CHAR and VARCHAR types if they're
implemented exactly the same way ? >>

Parsing support.

--
Tim Young
Elevate Software
www.elevatesoft.com

Hello Tim,

> ElevateDB supports the VarChar type, but it is really irrelevant how we
> implement it as long as the performance is acceptable.  I think that in the
> day of 200+ gig hard drives that it doesn't really matter much if a little
> extra space is consumed on disk or not.

Well i think that VarChar can save a lot of space
when talking about thousand of records. Also since
it's smaller it would be easier and faster to backup!
(either compressed either not).

Now, if VarChars are slower than Char then i prefer Chars.
(I'm talking about a difference and not a small one like
 1-3% slower)
--
Charalabos Michael - [Creation Power] - http://www.creationpower.com -
http://www.creationpower.gr

Hello Tim,

> No.  It will support Char and VarChar, which are implemented exactly the
> same way.  Char will not introduce space padding, contrary to the ANSI
> standard (this is legacy crap anyways - if the developer or user wants
> spaces, then they'll put them in).  However, both Char and VarChar will
> preserve leading/trailing spaces if they are in the text, unlike DBISAM.
> Also, the "NATIONAL" variations will be parsed and mapped back to the two
> types since, in the Unicode version, Char, VarChar, and their National*
> variations, will all support Unicode characters.  Likewise, the ANSI version
> of ElevateDB will not support Unicode at all.  We're looking to the future
> with this design since Unicode will be the standard character set in a
> fairly short period of time, and I didn't want to get into mixing ANSI and
> Unicode support for such a short period of time.

You mean that ElevateDB will come in 2 different variations ?
(One for Ansi and one for Unicode) ?

--
Charalabos Michael - [Creation Power] - http://www.creationpower.com -
http://www.creationpower.gr

Hello Ole,

> What's the purpose of having separate CHAR and VARCHAR types if they're
> implemented exactly the same way ?

A good question!

--
Charalabos Michael - [Creation Power] - http://www.creationpower.com -
http://www.creationpower.gr

Michael,

<< You mean that ElevateDB will come in 2 different variations ? (One for
Ansi and one for Unicode) ? >>

Yes.

--
Tim Young
Elevate Software
www.elevatesoft.com

Michael,

<< Well i think that VarChar can save a lot of space when talking about
thousand of records. Also since it's smaller it would be easier and faster
to backup! (either compressed either not). >>

Space savings always comes at the price of computational complexity, and
that adds more time than it saves in a lot of cases.   Think of it this way,
do you think that it is faster to read 10 megs in 1 meg chunks, or 4 megs in
1k chunks ?

--
Tim Young
Elevate Software
www.elevatesoft.com

Roy,

<< Did I read that right - VARCHAR will preserve trailing spaces? >>

Yes.

<< I hate to think of the amount of work I'll need to do if trailing spaces
are preserved >>

Why ?  Do your users or your application traditionally add spaces to the end
of strings ?


--
Tim Young
Elevate Software
www.elevatesoft.com