Common Data Services is an interesting service that is in the hands of Flow, PowerApps and PowerBI. Today I read an interesting blog post by Pieter Veenstra that inspired me to write this post.
What is Common Data Service?
CDS is a service that allows you to store data in a relational model integrated with Dynamics365 (because it comes from it), but also (and maybe most of all) PowerApps, Flow and PowerBI. This service allows you to securely store and manage business application data from the cloud. You can read more about CDS here.
For me, however, CDS is a defective relational database. In fact, we can connect to it from the level of the above platforms, but its management is unfortunately very limited:
- No access to the server on which this database stands. So we can not add resources to make it run more efficiently, as we can do for SQL server (adding space / CPU / memory) or DTU for Azure SQL Db.
- No access to data container. So, we can not, for example in the case of the SQL database, optimize its operation by changing the auto-shrink setting, reorganize the indexes in tables, etc.
- Limited access to the created OOB entities. That is, we can do everything (CRUD) with Custom entities and Custom fields, but with Standard entities / fields it is not so easy. We can expand them, but you can not remove them.
- Many functionalities are accessible only through API. So if you have not coded in C # or WebAPI or have already forgotten how to do it, you will not configure functions such as auditing entities or fields unfortunately. However, if it does not scare you, I recommend this part of the documentation explaining how to work with the API.
- CDS does not convince to itself in terms of efficiency. At the beginning of this post I referred to the Pieter Veestra’s post , who made a very interesting comparison of the performance of the Read-Write operation between the CDS and the SharePoint list on his blog. In this comparison CDS not only was slower, but also had a limit limited to 5,000 items on the list.
It’s worth to use CDS anyway!
Reading the above 5 points one can gets the impression that it is best to quickly forget about Common Data Services and focus on other data sources. But it does not have to be that way. What is on the one hand a nuisance to CDS is simply its characteristic feature on the other.
CDS is available OOB and is not intended to be another data source that requires configuration. It’s here, ready to be used just like that. Now. As it is. Simple and handy relational database(s).
And what about its performance? Remember that GA of the Common Data Services took place in November 2016. It was then a very basic product (I would say the beta of the MVP of the product) without the possibility of creating complex relationships between entities or defining option sets (which is possible from January this year). In this light, CDS is still a relatively young product. Observing the way of launching new products by companies such as Microsoft, and also having myself some experience on the startup market, I know that no serious company will take risk of making complete and final product from the start, and the process of maturing the solution takes at least a few years. The requirement to indicate the direction of development of a new product, repair its defects (eg efficiency) and confirmation of its actual usefulness is … using it by customers!
Use it consciously
Right, “use it consciously”. But what if the product is still not mature and its configuration is uncomfortable or impossible? Answer is: Use it wisely. Use the Common Data Service taking into account its advantages and disadvantages. Use wherever it is possible (and there is customer approval for extra licenses – Plan 1 for applications using CDS, Plan 2 for managing CDS entities). Only in this way can we influence its development. CDS will certainly be further developed, and I know from some sources (although this is not declarations or assurances) that even to the point of possibility to install CDS on more controlled environments (eg Azure web service instance).
If, however, someone still had doubts about the use of CDS as a relational database, stay tuned – I’m going to write few more blog posts about advantages of CDS, use cases and show some examples.
Oh and btw, just in case I’ll remind you that “SharePoint is not a relational database”;)