Yes, it has a database that stores all of it’s information within it, but it is not a database.
Over the years I’ve been asked many times to take a customer’s existing database model and map it to Dynamics – i., pick up and replace.
This generally leads to a back and forth on how this should be done as we discuss legacy information, schemas that no longer apply or are used and features that can simplify the overall implementation of the schema.
I think part of the reason for this is the readability of the Dynamics schema whereas something like SharePoint and Skype For Business is much more obscured (or a bit harder to read) whereas Dynamics can be readily mapped to the SDK.
When “migrating” a schema it’s important to remember;
- Your current schema for state engines will be replaced with State/Status codes for Dynamics.
- Your user ownership will be replaced by createdBy/modifiedBy entries tied to an active directory (on premise or in the cloud) and not use application Ids.
- Many-2-Many tables will exist in Dynamics but will not necessarily be accessible to you.
- Auditing is a checkbox that you enable.
I think what would really benefit Dynamics in this regard, and where I feel the Solution Designer falls down, is not providing a proper Entity Relationship Model for both the logical and physical implementation. When talking with end users, it’s the logical they are more concerned with – “are all of our concepts within there” – and the developers who are more concerned with the physical – “can I get all my datatypes and fields in there”.
In the end, I urge customers not to think of their Dynamics implementation as database with an application on top of it, but instead of a platform that are creating, extending and debugging.
No code I know, but had to get this out there – it’s not a Database!