Prefixed tables, separate databases or row separation for multiple users sharing only part of data

Question

We are working on application in saas model - multiple users sharing small part of the data, and most of it is unique and accessible only per user. Also it is possible to share some info between each other.

Part of the system handles RMA service. Let's assume:

global/shared PRODUCTS and PRODUCENTS tables
user's tables eg. RMA, CLIENTS and many others with unique data
some users offer OUTSOURCING of their service to the others

The database is MySQL and the question is how to handle data separation between users, having common tables for all, in the context of scalability and maintenance?

1 create new DB for every registered user
2 create prefixed tables set for every user
3 separate data on row level

Schema is designed conforming n3f with pretty complex relations at some points.

Thank you in advance for any suggestions.

---- Edit:

Multiple TENANTS sharing some 'global' data (eg. Producents and products)
Multiple USERS per each tenant

scenario: A TENANT XYZ can be visible to other TENANTS as a service provider, so others can use XYZ's services

My main concern is, how to handle multi-tenant architecture. will it be more efficient to serve data from one database with filter checking what data is accessible for given tenant
OR
better setup single database per tenant?

Answer 1

There are a couple of ways to achieve this. Let me jot down my views. Base 1. Have a design that allows you to mark which entity data are accessible to which tenant's users.

Scenario 1: Unified View Data listing based on tenant accessibility. In this scenario, the end user will be viewing the entire set of data as per the permission from each tenant.

Scenario 2: single tenant view The logged in user has to switch to the context of a tenant to view the data that this user can view. In this case, the user by default can view his own tenant data, upon requirement to view the service admin data, he has to impersonate himself as a service admin user (impersonation comes into picture since he is given view access to some part of the data.).

Scenario 2 is bit easy and robust in implementation point of view.

Share with us your understanding.