CDS Entity and SQL Table

[Former Member]

Dear Community,

I'm a newbie in HANA and I have no clear the difference between a CDS Entity and SQL Table.

We are migrating all our datawarehouses to HANA to build Design Studio Dashboards, up to now we have imported all our Tables in HANA importing the data throug CVS files. I guess that the new column store tables created by the import wizard in SAP HANA Studio are SQL Tables, aren't they?

In a near future surely we have to modify our tables, adding new fields, changing  other fields, making new relationships. Are CDS Entities more flexible than  SQL Tables?

Regards

Alvaro.

[pfefferf · Accepted solution]

Hello Alvaro,

a CDS entity is the definition (design-time) of a table for which a runtime object (what you call an SQL table) will be generated in a specified schema.

Design-time objects brings advantages regarding the maintainability and lifecyle management (for instance if you create a table via a CREATE TABLE statement, then you have to do this on every system manually or with additional tooling support, using a CDS entity in an e.g. hdbdd file triggers the creation automatically when the file is imported to the target system(s)).

For more information you can check:

• Creating the Persistence Model in Core Data Services - SAP HANA Developer Guide for SAP HANA Studio ...
• http://help.sap.com/hana/SAP_HANA_Core_Data_Services_CDS_Reference_en.pdf

Best Regards,

Florian

[nithinu · Accepted solution]

Hi Florian,

Is the recommended way to use CDS table ? I believe all the functionalities of a normal SQL table will be same with the CDS table. I am also a newbie here and that is why these questions !

Thanks,

Nithin 

[Former Member · Accepted solution]

Hello Nithin,

As far as I've read the CDS Entity (your CDS table), is a Design-time object (as Florian said) when you activate this Design-time object HANA creates the correspondent catalog object, in this case a table. I've understood that the benefits of having Design-time object are the flexibility to changes because you can replicate the changes of a particular object only activating the correspondent design-time object in the target systems by HALM (HANA Application lifecycle manager) (as Sergio mentioned) instead of executing the particular change in every target system.

So in the end a SQL Table is the catalog object that can be generated by a CDS Entity, an abstraction of a Table.

Correct me if I'm wrong.

[SergioG_TX]

Alavaro,

glad to see you here again.

the CDS entities are design time objects that can be transported from environment to environment via HALM (HANA Application lifecycle manager) without the need to having to re-run sql statements on each environment (traditional deployments).

the design time object when activated creates a run time object, so when you create an entity in CDS and you activate that file (with one or more entities) then your (entity)table will be created in the schema specified.

when you add / remove fields in CDS, it will be as simple as including/removing the column definition in the CDS file.

making the relationships may be easier as you can also create associations, etc of your entities...  whether you do sqlscript or cds you will still create tables, however, if you use sql statements, you will need to run those statements again on the upstream environments during your migration. cds will be simpler to migrate

here is the official documentation for CDS http://help.sap.com/hana/SAP_HANA_Core_Data_Services_CDS_Reference_en.pdf