Login ProductsSalesSupportDownloadsAbout |
Home » Technical Support » DBISAM Technical Support » Support Forums » DBISAM General » View Thread |
Messages 1 to 10 of 49 total |
Varchar2 |
Fri, Mar 10 2006 9:17 PM | Permanent Link |
"Lance R." | 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 |
Sat, Mar 11 2006 6:27 AM | Permanent Link |
Michael Baytalsky | > 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 |
Sat, Mar 11 2006 7:12 PM | Permanent Link |
Charalabos 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 |
Sat, Mar 11 2006 8:51 PM | Permanent Link |
"Ole Willy Tuv" | 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 |
Sat, Mar 11 2006 9:07 PM | Permanent Link |
"Ole Willy Tuv" | << 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 |
Sun, Mar 12 2006 4:03 AM | Permanent Link |
Roy Lambert NLH Associates Team Elevate | 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 |
Sun, Mar 12 2006 1:17 PM | Permanent Link |
Michael Baytalsky | > 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 |
Sun, Mar 12 2006 5:47 PM | Permanent Link |
Charalabos 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 |
Mon, Mar 13 2006 12:17 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | 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 |
Mon, Mar 13 2006 12:21 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@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 |
Page 1 of 5 | Next Page » | |
Jump to Page: 1 2 3 4 5 |
This web page was last updated on Wednesday, May 15, 2024 at 08:40 PM | Privacy PolicySite Map © 2024 Elevate Software, Inc. All Rights Reserved Questions or comments ? E-mail us at info@elevatesoft.com |