cancel
Showing results for 
Search instead for 
Did you mean: 

"Char" type in core data services

Former Member
0 Kudos

Hi Guys,

CDS has a primitive data type "String" which on activation gets converted into "nvarchar' SQL data type. My question is can we have "char" data type using CDS, is there any performance implication of using nvarchar over char and vice versa.

Regards,

Vijay.

Accepted Solutions (1)

Accepted Solutions (1)

lbreddemann
Active Contributor
0 Kudos

CHAR is not supported by SAP HANA anymore (actually since quite a while) so it's just consequential to not allow it in CDS.

Sure enough there are implications by using different data types:

- char is not stored more efficiently but instead needs to be padded with blanks at the end

- during processing, char requires always the maximum memory, whereas (n)varchar can optimize memory usage based on the actual data

All in all, you'll be much better off using (n)varchar over char.

thomas_jung
Developer Advocate
Developer Advocate
0 Kudos

Actually we do plan to add CHAR along with all the other HANA specific types to CDS/HDBDD in SPS09.  Here is the list of all the planned additions:

@nokey

entity SomeTypes {

  a : hana.ALPHANUM(10);

  b : hana.SMALLINT;

  c : hana.TINYINT;

  d : hana.SMALLDECIMAL;

  e : hana.REAL;

  f : hana.CHAR(10);

  g : hana.NCHAR(10);

  h : hana.VARCHAR(10);

  i : hana.CLOB;

  j : hana.BINARY(10);

  k : hana.ST_POINT;

  l : hana.ST_GEOMETRY;

};

lbreddemann
Active Contributor
0 Kudos

Interesting move.

How come CDS is going to support data types that are not supported anymore?

Or is this another documentation bug (Data Types - SAP HANA SQL and System Views Reference - SAP Library)?

The information modeler doesn't allow those "abandoned" data types either, so it seems actually wanted to not have them anymore.

Doesn't look too consistent to me.

Can you provide some clarification on that?

thomas_jung
Developer Advocate
Developer Advocate
0 Kudos

I can't comment on type support in the modeler. I only know that was the list of TYPE newly added to CDS in SPS09.

Former Member
0 Kudos

Hi Thomas & Lars,

Thanks for the valuable inforamtion, I come from MySql background, AFAIK char is always preferred over "varchar" as it is fixed length or static which helps in better performance. Is that still true for HANA?

Regards,

Vijay.

Former Member
0 Kudos

Hi,

Found this blog http://www.saphana.com/community/blogs/blog/2013/04/07/best-practices-for-sap-hana-data-loads

where he says "Avoid using VARCHARs if you don't need them. Fixed width CHAR is better for smaller fields, and INTEGER fields are even better. VARCHARs have a cost, and don't compress as well."

If it is true then why sap has decided to get rid of CHAR data type in the first place?

Regards,

Vijay.

lbreddemann
Active Contributor
0 Kudos

Well, maybe it's time to check up on what you think it's true about char vs. varchar in SAP HANA. See ...

Former Member
0 Kudos

Back when I wrote that post I tested and found that VARCHARs were less efficient for storage and processing. However that was a long time ago back in Rev.21 of HANA and times change.

Since then, VARCHAR is more efficient and CHAR is deprecated.

Former Member
0 Kudos

Hi John,

Thanks for the clarification

Regards,

Vijay.

Former Member
0 Kudos

I updated the blog to be more up to date. Hopefully this avoids confusion for someone in the future.

thomas_jung
Developer Advocate
Developer Advocate
0 Kudos

So what happened was that CDS brought over all the data types from HANA regardless of their status. That has since been discussed and will try to be removed (CHAR/NCHAR). However it is relatively late in the process for SPS09 and it remains to be seen if CHAR/NCHAR will be removed in time or not. Either way key points:

1. If CHAR/NCHAR show up; don't use them

2. CDS does bring over all the missing HANA data types that have been a gap in the past. We do get more control to use all the supported HANA data types include GeoSpatial types.

Answers (1)

Answers (1)

Former Member
0 Kudos

Thanks for the reply