Why does SAP HANA not support CHAR/NCHAR as official data type?

[sebflaesch]

The SAP HANA doc says that CHAR/NCHAR are not "officially supported"... one should use VARCHAR/NVARCHAR instead.

In the context of database migration, when you come from another type of DB, you have to convert all CHAR/NVCHAR columns to VARCHAR/NVARCHAR and you lose the distinction between [N]CHAR and [N]VARCHAR columns.

I would like to store codes like AXB-345 with fixed length into a CHAR(7), not VARCHAR.

Also: You know certainly that CHAR/NCHAR have different blank padding semantics as VARCHAR/NVARCHAR and one may expect such behavior.

Just want to know if there is a plan to support CHAR/NCHAR "officially" in future versions.

Even if the semantics of [N]CHAR would be the same as [N]VARCHAR, one will lose the type distinction regarding database schema definition. When using Oracle, SQL Server, DB2, you can use CHAR and VARCHAR. When moving to SAP HANA, all must be VARCHAR...

[lbreddemann]

I don't know the reason behind the de-support for (N)CHAR, so I cannot answer the question.

While I do understand your points, I'd really be interested, what advantage you would gain from the fixed length data type.

Most relevant client languages/frameworks nowadays map to variable string data types. Even the old-fashioned type system of SAP Netweaver has no issue mapping the variable length variant (not surprising that one, I know).

Practically speaking, the vast majority of cases I can think of literally can exchange the (N)CHAR with the (N)VARCHAR data type in the DB schema and see no negative impact to the application. (in fact, network traffic will be reduced for values not fully using the full length)

So besides the point for generality and everlasting compatibility with data types (and padding semantics) from half a century ago, what do you say is a good reason to pick the fixed type for a newly created database? Or asked the other way around: why have such a data type in the first place?

[sebflaesch]

Hi Lars and thanks for your answer!

You remarks make sense, but let me give you the background:

Our product Genero BDL is based on Informix 4GL, where semantics of CHAR vs VARCHAR are important.

In the language, CHAR variables are blank-padded.
When you define CHAR(10) and set a value of "abc", you get "abc......." with 7 trailing blanks.

The programming language is very close to SQL.

When fetching string data into variables that will then be displayed in a graphical widget like a table or listview, I agree that VARCHAR does the job no problem.

However in BDL/4GL, there are areas when CHAR blank padding auto-formats data output and this is very cool.

There is also a text-based report feature where CHAR blank padding is mandatory to properly align report output.

We are in a business where millions of lines of Informix 4GL legacy code must run identically. The challenge is to make these programs work with SAP HANA, for customers willing to migrate to SAP HANA.

Furthermore, as a DB designer, I would use CHAR for small, fixed length, "code" data and VARCHAR for medium / large text data like names, addresses...

CREATE TABLE member (
mem_num INTEGER GENERATE ALWAYS AS IDENTITY (...) PRIMARY KEY,
mem_code CHAR(10) NOT NULL, <-- always 10 chars
mem_name VARCHAR(50) NOT NULL,
mem_addr VARCHAR(200) NOT NULL,
....
)

Seb

[lbreddemann]

Thanks for the explanation Sebastian. That's pretty much what I expected.