I want to create a multi tenant app, but I have never worked with multi tenancy apps.
I would create a database global database for users and some data like zipcodes, countries, ...
And each tenant has his own database so they can store their data on their own server.
Now I have 2 problems:
If I connect to the user database I need to access to the shared
(global data), e.g. zipcode - is this possible?
I would create
dynamic forms, so the users have a table for the forms and the
fields and a datatable. The advantage of this method is that each
user can modify his forms, but is this a good practise?
Normally you have fixed table schemas like: customers (id, name, ...), addresses, so on.
Is there any better idea?
Hope someone know's what I mean and can help me :)
Thanks
Regards
Alex
mysql "databases" aren't real databases - they're just schemas inside one database.
You can query between schemas, and have foreign keys between schemas too. Just use the fully-qualified name: schema_name.table_name.
Dynamic tables (EAV) are almost always a bad idea. Use existing data model patterns first. If you really, really must use user-defined fields, then follow Martin Fowler's advice.
Related
I need to create such a structure, there is a category of products, each category stores its own information, for example, be entered phone information when selecting a phone category, computer information must be entered when selecting a computer category, How to create this structure in a clean database? , how is it done in a real project?
Before creating a 'structure' in a DB you need to design your Entity-Relationship Diagram.
This means that you need to decide the Entities of your problem, these would be your tables later in the DB, the Relationships between the entities, these have multiple ways that can be depicted in the tables based mainly on their cardinality and then the properties of the entities, which will be the fields of the tables in your DB.
I think that you need to start from that, create the ER Diagram and then try to model it into the DB.
Let us say I need to design a database which will host data for multiple companies. Now for security and admin purposes I need to make sure that the data for different companies is properly isolated but I also do not want to start 10 mysql processes for hosting the data for 10 companies on 10 different servers. What are the best ways to do this with the mysql database.
There are several approaches to multi-tenant databases. For discussion, they're usually broken into three categories.
One database per tenant.
Shared database, one schema per
tenant.
Shared database, shared schema. A tenant identifier (tenant key) associates every row with the right tenant.
MSDN has a good article on the pros and cons of each design, and examples of implementations.
Microsoft has apparently taken down the pages I referred to, but they are on on archive.org. Links have been changed to point there.
For reference, this is the original link for the second article
In MySQL I prefer to use a single database for all tenants. I restrict access to the data by using a separate database user for each tenant that only has access to views that only show rows that belong to that tenant.
This can be done by:
Add a tenant_id column to every table
Use a trigger to populate the tenant_id with the current database username on insert
Create a view for each table where tenant_id = current_database_username
Only use the views in your application
Connect to the database using the tenant specific username
I've fully documented this in a blog post:
https://opensource.io/it/mysql-multi-tenant/
The simple way is: for each shared table, add a column says SEGMENT_ID. Assigned proper SEGMENT_ID to each customer. Then create views for each customer base on the SEGMENT_ID, These views will keep data separated from each customers. With this method, information can be shared, make it simple for both operation & development (stored procedure can also be shared) simple.
Assuming you'd run one MySQL database on a single MySQL instance - there are several ways how to distinguish between what's belonging to whom.
Most obvious choice (for me at least) would be creating a composite primary key such as:
CREATE TABLE some_table (
id int unsigned not null auto_increment,
companyId int unsigned not null,
..
..
..,
primary key(id, company_id)
) engine = innodb;
and then distinguishing between companies by changing the companyId part of the primary key.
That way you can have all the data of all the companies in the same table / database and at application level you can control what company is tied to which companyId and determine which data to display for certain company.
If this wasn't what you were looking for - my apologies for misunderstanding your question.
Have you considered creating a different schema for each company?
You should try to define more precisely what you want to achieve, though.
If you want to make sure that an HW failure doesn't compromise data for more than one company, for example, you have to create different instances and run them on different nodes.
If you want to make sure that someone from company A cannot see data that belong to company B you can do that at the application level as per Matthew PK answer, for example
If you want to be sure that someone who manages to compromise the security and run arbitrary SQL against the DB you need something more robust than that, though.
If you want to be able to backup data independently so that you can safely backup Company C on mondays and Company A on sundays and be able to restore just company C then, again, a purely application-based solution won't help.
Given a specific DB User, you could give a user membership to group(s) indicating the companies whose data they are permitted to access.
I presume you're going to have a Companies table, so just create a one-to-many relationship between Companies and MySQLUsers or something similar.
Then, as a condition of all your queries, just match the CompanyID based on the UserID
in my file Generate_multiTanentMysql.php i do all steps with PHP script
https://github.com/ziedtuihri/SaaS_Application
A Solution Design Pattern :
Creating a database user for each tenant
Renaming every table to a different and unique name (e.g. using a prefix ‘someprefix_’)
Adding a text column called ‘id_tenant’ to every table to store the name of the tenant the row belongs to
Creating a trigger for each table to automatically store the current database username to the id_tenant column before inserting a new row
Creating a view for each table with the original table name with all the columns except id_tenant. The view will only return rows where (id_tenant = current_database_username)
Only grant permission to the views (not tables) to each tenant’s database user
Then, the only part of the application that needs to change is the database connection logic. When someone connects to the SaaS, the application would need to:
Connect to the database as that tenant-specific username
New to this, I am creating a database for an application. As the schema is becoming visually complex very rapidly, is it possible/feasable/recommended to have the same user_table in multiple schema?
For example, the blogging schema would have the user_table and the rest of the tables related to this activity. The shopping schema would again have the same user_table and the tables to manage the shopping activity. And so forth....
The objective would be to separata the plenty of tables in different schemas so to simplify the overall managements.
In another post, someone suggested creating a synonym in one the of schemas, referencing the other schema table. Is it the way to go or am I totally misrepresenting problem and solution?
Thank you for your time reading this.
A user table serves two diffent features, each in its own schema:
Sharing tables between schemas is not directly possible. There's a feature called federated tables, which however is not enabled by default and must be enabled at compile time of a MySQL server. So, it's rather not available for your task.
Instead you have only two options:
Use a single schema to avoid data duplication.
Use multiple schemas and maintain tables like the user table in each of them in parallel (by executing the same update queries on each of them).
I'm trying to design a system for giving users permissions on objects. Currently I have a database schema where there are roles and each role can have a permission on multiple 'securable objects'. Such an object can be a sensor, an other user or whatever new thing we might add later. So I have a table role_permissions that links a role to a user, sensor etc. A user can also have a permission directly, so there would also be a user_permissions table that link a user directly to a user, sensor etc.
Now the field that refers to a securable object can't be a foreign key, because the target objects can be of different types and thus come from different tables.
The problem I'm facing right now is how I can make Hibernate work with this. One-to-many relations won't work here I think because Hibernate can't possibly know in which table to look.
An alternative would be to create a role_user_permissions table, a role_sensor_permissions table, a user_user_permissions talbe, a user_sensor_permissions table, and a new role_other_type_permissions table + user_other_permissions table for every securable type that's in the system. So for every single type that needs to have permissions on it I would need 2 new tables to manage the permissions.
But now the database is cluttered with permissions tables that actually serve the exact same purpose but for different types. However, Hibernate IS happy to take this because through foreign keys it always knows what table to look in and what type the object is.
Does anyone know a best practice to solve this issue?
Thanks in advance,
Stan
Here is a question from a newbie. I need to store music data(URL, artist ...) for each user. Should I put all data in one single table with distinct keys for each user. Or maybe it is good idea to have separate tables for each user.
I am making an online player.
Thanks in advance
You will create huge database if you are going to create seprate table for each user, make a table structure that will contain entries of all user in single table....
Create a single table with different user privileges for ex create an
group column table and provide different grouids to different users
e.g. groupid =1 for admin ,2 for normal user etc.
A separate table for each user is not appropriate.
You need one table for the music data (URL, artist, ...).
If the only item you store about users is the name, you can put that into the music data table as well without violating database design principles too much.
As soon as you store additional information about users (e.g. password, e-mail address) you need a second table for the user data and connect the music data to the user data via a foreign key in the music data table (or, in case of a n:m relation, a third table).
If you are looking for further information about database design, keywords are functional dependency and normalization.
Enhanced relationship diagrams may help you in designing your database. It might be worth mapping out your proposed database using these diagrams before you implement them.
This is a good tool to make sure you have a correct database design for you and as previously said below deal with functional dependency and normalization.
This is a good website to help you if you haven't done this before: http://users.csc.calpoly.edu/~jdalbey/205/Lectures/HOWTO-ERD.html