I am looking towards building a multi-tenant Laravel app which is a school management system that has one code-base but has multiple databases for each school. This system will have 800 schools (tenants), and each school will have its own users (teachers and students).
How can I implement the above with Laravel? Can or should I use a package or the is laravel native implementation of the above?
Every time a school is registered, how can I automatically create a subdomain on a domain, and automatically load the new tenant on AWS EBS or Heroku
How can I run one migration to all multiple databases ?
yes, you can do it by declaring multiple database connections in your config file and the set connection dynamically in each fetch queries and also migration queries.
in normal queries:
DB::connection('some dynamic connection name')->...
or in migrations:
Schema::connection('connection name')->....
Related
I made a Spotify app that analyzes user data and manages interactive features by writing the API responses to a PostgreSQL database. The developer rules state that basically I have to delete the data when the user is not actively using my app.
Is there a way to automate this on the server (I'm using AWS Lightsail/Ubuntu) to do it daily? Would I need to add a datetime column to all of my tables and follow one of these: https://www.the-art-of-web.com/sql/trigger-delete-old/? Or is there a better way?
I'm relatively new to databases - I've used postgresql in the past to create databases stored on my computer and accessed only by myself.
I'm currently designing a database that will be used and edited by multiple people (10-15 max) living in different parts of the world. What is the best way to ensure we will all have access to the most current version of the database? Is it best to continue storing the database on my individual computer? Should I host the database on a cloud server? I've read that it is dangerous to store databases on Dropbox.
We are social science researchers organizing our data into a single database.
Based on your comment about not always be on and connected, it seems to me that the cloud service is the way to go for you. There are two approaches there, just rent a machine ("AWS EC2") and install the database software and manage the database yourself, or use a cloud provider's managed database service ("AWS RDS"). The names are just by way of a concrete examples, there are other providers of each type of service.
I am currently working on a new Web Application. I really love the idea behind firebase (augularfire) for the realtime data sync. But I can't figure out how to organize all the data, make each customer (enterprise) have his own data, and ensure no data is shared between each enterprise.
In a regular MySql server, I can create a database per enterprise (best implementation for speed and security) or simply add a table Enterprise and a table Customer with enterprise_id. Which is the best approach in a Firebase DB?
I am working on a phonegap project to build a cross platform mobile app, and came to know from a website that the app's database can be deployed/built with "database.com".
The procedure is well explained but I have one question -
how to sync the database available on database.com with a database on a local server?
i.e. for e.g., if a client has his database (of his desktop application) on his local server and he requires a mobile app of the same now, what is the procedure to be followed in "database.com" to sync his server's database with the database on "database.com"?
PS: I need to use "database.com" for my database because I want to maintain it on cloud, and I do not have capability to maintain a local server.
You might need a service for data syncing if it is to be more than once. I work on a project that does exactly this.
www.overcast-suite.com
Otherwise, model your tables to Salesforce Custom Objects, export the data on the local server to CVS and use the Data Loader to import.
I have to use ASP.NET MVC 3 or above and SQL Server 2008. As per Multi-Tenant Data Architecture post, there are 3 ways to implement multi-tenancy
Separate Databases
Shared Database, Separate Schemas
Shared Database, Shared Schema
I have following details:
User should be able to backup and restore their data.
No of tenants : 1000 (approx)
Each tenant might belong to different domain(url).
It must support monitoring and management of tenants.
It must support user authentication and authorization for each tenant
It must support tenant customization(enable disable features set)
No of tables in each tenant: 100 (initial)
I would like to know what your experience says about which approach is more suitable for the project considering Economic and Security? Is there any good real time example(open source project) similar to this? I can use one dedicated server for the project.
Your requirement that users should be able to backup its data, can be achivable more easily with approachs 1 and 2... since it will be a native database task.
If you are in approach 3 (shared-shared), you will need to develop the logic to extract all the rows belonging to a single tenant and export it in a xml file or something like that. Then if you need to allow users to restore that backup file, you need to develop a restore logic.
I think this is the only requirement that could make you move away from #3.
Once you set your database using TenantID columns in your table... you can easily use one database for 1 tenant or a small group of tenants if your client is heavily concerned about security. For instance, you could have one database holding tenants that are not paying (free/demo accounts) and paying customers in another one. This way you are using approach #3, but being able to behave as #1 if you need it.
::: BONUS :::
AUTHENTICATION:
You will need to extend the SQL Membership and Role Providers used in your MVC3 app... so that a user login is valid only in the Tenant it belongs to.
MULTIPLE DOMAINS
Here you can see some approaches using ASP.NET MVC3 Routing:
MVC 3 Subdomain Routing
I would always use (3) Shared Database, Shared Schema.
If you want an example, how about Wordpress, Joomla, or any other popular open source web-based project?
Creating separate schemas or databases on a per-tenant basis will lead to massive management overhead. Not to mention increased complexity of analysing your data, costs, etc.
The only reason you'd go for (1) (or perhaps 2) is if you were to give your actual tenant direct access to some/all of the database. As you're using ASP.NET MVC 3, this isn't a consideration.