With the new release Data Areas are implicitly implemented as schemas in the backing database. As you can also apply schema behaviours and rules per table, this can become a bit messy (or make users not use these functionaliities). It also makes it unclear what a best practice for implementation would look like.
It is understandable to have the features that exist in 20.10.x available to be able to migrate existing projects into the new release. I think it would be better to relegate this functionality to deprecated (i.e. hidden for new implementations). That would make the setup something like:
- Instance (implicitly a database)
- Data Area (implicitly a schema)
- Tables
- Views
- ..
- Data Area (implicitly a schema)
This allows users to split an instance into separate areas, for instance to have separate staging per source. I would then add an option to push “technical tables” to separate schemas, i.e. _R _I _M _PK etc.
Needing to go to table settings and individually assign schemas takes too long to be really useful and should no longer be required in the new release outside of dealing with migrated implementations.
Additionally, it would be good to be able to perform data movements between instances as this allows you to create a setup where you have separate instances for staging and a central instance for merging and MDW storage. This allows you to have multiple smaller Hyperscale instances and not be limited by log I/O thereby greatly increasing the throughput and size applicability.
