Thanks for sharing all of this Byron, I liked that you described the "why" behind a lot of these concepts.
One thing that stuck out to me was the use of child databases and how they could each have their own schemas. That seems cool, but in practice, how can you safely build a user interface around that when you can never really know what underlying data you have access to? Perhaps it's only for a certain use case.
The multi-tenancy feature is designed to be used on a project or team basis in order to intentionally split the data. So one child database can be used for your product and another for your internal ops for example. This means that each assigned team would be aware of the way they decided to design their data.
I create one database per app and then decide how it should be modelled. With regards to not knowing what underlying data, this is the purpose of indexes which can be created to query data in whatever way you deem fit :)
Thanks for sharing all of this Byron, I liked that you described the "why" behind a lot of these concepts.
One thing that stuck out to me was the use of child databases and how they could each have their own schemas. That seems cool, but in practice, how can you safely build a user interface around that when you can never really know what underlying data you have access to? Perhaps it's only for a certain use case.
Thanks for the comment.
The multi-tenancy feature is designed to be used on a project or team basis in order to intentionally split the data. So one child database can be used for your product and another for your internal ops for example. This means that each assigned team would be aware of the way they decided to design their data.
I create one database per app and then decide how it should be modelled. With regards to not knowing what underlying data, this is the purpose of indexes which can be created to query data in whatever way you deem fit :)
Hopefully this answers your questions.
Ah okay that clears it up a bit, thanks for the explanation there