cockroach-staging / hello-world

0 stars 0 forks source link

S14: As the CIO of Unimarket, I want to support multi-tenancy without relying on a "tenant id" column so I can separate tenants without having to incur risk by relying on developers to check customer IDs at the application level. #185

Open exalate-issue-sync[bot] opened 4 years ago

exalate-issue-sync[bot] commented 4 years ago

As the CIO of Unimarket, I want to support multi-tenancy without relying on a "tenant id" column so I can separate tenants without having to incur risk by relying on developers to check customer IDs at the application level.

exalate-issue-sync[bot] commented 4 years ago

Rachel Casali commented: https://unimarket.com/

"Unimarket is are keen to keep things in one database. Their current MariaDB setup is run in one database and one schema, and separated with a tenant identifier at the row level. This is not really sufficient now, there are some drawbacks. It depends on developers and people accessing to make sure only reading from tenant identifier. Hibernate has built-in support for multi-tenancy at a certain level, so trying to find a more de-risked solution.

Robert offered some options: database level and views. Views might not work because they aren't update-able, need to protect from selects and inserts. Don't need join updates. Update-able views is potentially a requirement. Anything that controls access to a potential row would work, so the geo-partitioning approach might work. Views aren't ideal - row-level access controls would be better."