Having been more involved on these forums for the past few weeks, I realized there are quite a few SQL Guys like me around. (I thought I was an oddity)
Until recently, there was a gentle "live and let live" attitude between SQL and CDS. We didn't get much love (see the ideas on triggers or procs) but we were more or less free to do our own things in a nice cost-efficient manner. Now, with the new licensing, the attitude has switched to a much less subtle "convert or die" message... with the expected pushback from the community as a result.
Yet some folks at MS are curious about why we won't use CDS as our go-to data storage. I have my own reasons, which I'll share in the next post, but I'm curious about yours. Are you able to explain why you simply won't switch to CDS overnight? Obviously, I don't believe the "all-in on CDS" strategy is going to change anytime soon. The goal here is to provide insights and understanding to MS as to why we "resist" CDS (a genuine question I've been asked by different MS employees already).
To temper my comments, let me start by saying that I DO believe that CDS has a part to play in the Power Platform. It's a great low-code DBMS sitting somewhere between Sharepoint lists and full Az SQL DB as a backend option, not unlike front-end sophistication can vary between highly managed model-driven screens all the way to PCF components. As far as I can tell, CDS' main value proposition is :
No need to learn SQL (not an advantage to us, but will be for some)
Common model with Dynamics (if your client uses that)
Native REST API querying, something vanilla Azure SQL DB doesn't offer
I have edited my earlier post as I don't want to give incorrect info in relation to the ability to use 'JOIN' equivalent in CDS:
I believe first level joins can be made in some circumstances - in this case, because the link between Job and Appointment is 'polymorphic' (an appointment might be for a job, it might be for something else) then the 'filter by a first level join' functionality (filter appointments by an attribute of the related job) does not work... Don't get me started on the use of polymorphic relationships from a data modelling perspective!