Need to update my single user app database to allow multiple users, how to modify database schema?

Question

I built an app for a local group who runs frisbee leagues not too long ago. I am wanting to build this out, and make it something that I can provide to other groups.

Jist: people sign up to play, app creates teams, app creates schedules, there are admins for each group who can manage their leagues

The problem is, I have one database, and it was originally set up to only deal with one group's leagues. How would I go about reworking the schema to allow multiple groups to be able to log in and modify only their own leagues.

My thought was to create an "account" table, and tack "account_id" to every table. Is this a good approach? I have attached the schema, so you should be able to see what I have thus far!

Note: I am building this in Codeigniter (php) and MySQL.

Answer 1

Multiple clients; one hosted application. You're describing a multi-tenant database.

When you build a multi-tenant database, you need to consider

• querying
• cost
• data isolation and protection
• maintenance, and
• disaster recovery.

Multi-tenant solutions range from one database per tenant (shared nothing) to one row per tenant (shared everything).

"Shared nothing", "separate database", or one database per tenant

• Most expensive per client. (Large numbers of clients imply large numbers of servers.)
• Highest degree of data isolation.
• Disaster recovery for a single tenant is simple and straightforward.
• Maintenance is theoretically harder, because changes need to be carried out in every database. But your dbms might easily support running stored procedures in each database. (SQL Server has an undocumented system stored procedure, sp_msforeachdb, for example. You can probably write your own.) "Shared nothing" is the most easily customizable, too, but that also raises more maintenance issues.
• Lowest number of rows per table. Querying speed is near optimal.

"Shared everything", or "shared schema", or "one database per pl.net"

• Least expensive per tenant.
• Lowest degree of data isolation. Every table has a column that identifies which tenant a row belongs to. Since tenant rows are mixed in every table, it's relatively simple to accidentally expose other tenant's data.
• Disaster recovery for a single tenant is relatively complicated; you have to restore individual rows in many tables.
• Structural maintenance is simpler, given that all tenants share the tables. It increases the communication load, though, because you have to communicate and coordinate each change with every tenant. It's not easily customizable.
• Highest number of rows per table. Quick querying is harder, but it depends on how many tenants and how many rows. You could easily tip over into VLDB territory.

Between "shared nothing" and "shared everything" is "shared schema".

"Shared schema"

• Tenants share a database, but each tenant has it's own named schema. Cost falls between "shared nothing" and "shared everything"; big systems typically need fewer servers than "shared nothing", more servers than "shared everything".
• Much better isolation than "shared everything". Not quite as much isolation as "shared nothing". (You can GRANT and REVOKE permissions on schemas.)
• Disaster recovery for a single tenant requires restoring one of many schemas. This is either relatively easy or fairly hard, depending on your dbms.
• Maintenance is easier than "shared nothing"; not as easy as "shared everything". It's relatively simple to write a stored procedure that will execute in each schema in a database. It's easier to share common tables among tenants than with "shared nothing".
• Usually more active tenants per server than "shared nothing", which means they share (degrade) more resources. But not as bad as "shared everything".

Microsoft has a good article on multi-tenant architecture with more details. (The link is to just one page of a multi-page document.)