Tim,

is ElevateDB going to support varchar2 types (physical size 2
bytes[length] larger than actual size) like some DB's, such as Oracle?

Lance

> is ElevateDB going to support varchar2 types (physical size 2
> bytes[length] larger than actual size) like some DB's, such as Oracle?
How's that any different from varchar? I understand varchar and varchar2
are synonyms in Oracle now, am I not correct?

I'd rather ask if v5 will support nvarchar and nclob?


Michael

Hello Michael,

>> is ElevateDB going to support varchar2 types (physical size 2
>> bytes[length] larger than actual size) like some DB's, such as Oracle?
> How's that any different from varchar? I understand varchar and varchar2
> are synonyms in Oracle now, am I not correct?
>
> I'd rather ask if v5 will support nvarchar and nclob?

Well, VarChar support will not be available in ElavateDB
if i remember right! That's something i wanted. With
VarChar you can save disk space, but i guess it's slower
than standart "Char" types ? So if you use VarChar you
gain disk space but loose perfomance. (or i'm wrong ?)

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

Hi Michael,

<< Well, VarChar support will not be available in ElavateDB if i remember
right! That's something i wanted. With VarChar you can save disk space, but
i guess it's slower than standart "Char" types ? So if you use VarChar you
gain disk space but loose perfomance. (or i'm wrong ?) >>

I've never seen any performance issues with VARCHARs in database engines
like SQL Server or NexusDB.

The main point about variable-length character string data is how it's
represented at retrieval, not how it's stored. A correct implementation of
the VARCHAR type means that the value is right-padded with spaces to the
specified maximum length at retrieval, which I don't think DBISAM V4 does
currently.

Regards
Ole

<< The main point about variable-length character string data is how it's
represented at retrieval, not how it's stored. A correct implementation of
the VARCHAR type means that the value is right-padded with spaces to the
specified maximum length at retrieval, which I don't think DBISAM V4 does
currently. >>

Sorry, I mixed it up with the semantics of fixed-length character string
data (CHAR/CHARACTER). VARCHAR data is truncated at retrieval, while
CHARACTER data should be right-padded with spaces to the maximum length.
It's the latter I think DBISAM V4 doesn't do currently.

Ole

Me being thick again. What is varchar2 - if as Lance's post suggests its (physical size 2 bytes[length] larger than actual size) why - what's the point of it?



Roy Lambert

> Well, VarChar support will not be available in ElavateDB
> if i remember right! That's something i wanted.
I really hope you're not right ). But we'll see...


> With
> VarChar you can save disk space, but i guess it's slower
> than standart "Char" types ? So if you use VarChar you
> gain disk space but loose perfomance. (or i'm wrong ?)
I think it's really all about padding, like Ole suggested
below. CHAR is much easier to implement also, but as far as
performance concerned it's questionable: we're loosing
in more complex implementation of varchar, but gaining on
smaller data size. Performance, imo, depends on too many other
factors, like SQL optimization, implementation of indexes, etc.
Also, all engines have that and are performing quite fast,
so it can hardly be a real issue.


Michael

Hello Ole & Michael,

>> Well, VarChar support will not be available in ElavateDB
>> if i remember right! That's something i wanted.
> I really hope you're not right ). But we'll see...
>
>
>> With
>> VarChar you can save disk space, but i guess it's slower
>> than standart "Char" types ? So if you use VarChar you
>> gain disk space but loose perfomance. (or i'm wrong ?)
> I think it's really all about padding, like Ole suggested
> below. CHAR is much easier to implement also, but as far as
> performance concerned it's questionable: we're loosing
> in more complex implementation of varchar, but gaining on
> smaller data size. Performance, imo, depends on too many other
> factors, like SQL optimization, implementation of indexes, etc.
> Also, all engines have that and are performing quite fast,
> so it can hardly be a real issue.

Thanks both for the info. It's up to Tim to decide but
i think that it should be one of the top reasons for
ElevateDB to be competitive with other SQL Engines.
(The major SQL Engines are supporting VarChar with
 indexes. (Free ones too like MySQL)


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

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.

--
Tim Young
Elevate Software
www.elevatesoft.com

Michael,

<< Thanks both for the info. It's up to Tim to decide but i think that it
should be one of the top reasons for ElevateDB to be competitive with other
SQL Engines. (The major SQL Engines are supporting VarChar with  indexes.
(Free ones too like MySQL) >>

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.

--
Tim Young
Elevate Software
www.elevatesoft.com