This project has moved and is read-only. For the latest updates, please go here.

Support few companies on the same TicketDesk / DB

Oct 13, 2014 at 10:48 AM
Is it possible to use the same system for several companies ?
Oct 13, 2014 at 4:34 PM
Edited Oct 13, 2014 at 4:37 PM
If you mean one single TicketDesk DB supporting multiple ticketdesk web sites, then no. You could probably extend the source code fairly easily to support that scenario, but it isn't a built-in feature.
TD 2.5, which is in development now, will include a multiple projects feature... you may be able to achieve your goals by organizing companies as different projects, and still get by without having a strictly multi-tenant database --if that works depends on your goals and the level of isolation you might require
There are two approaches to multi-tenant databases that would make sense with a system like TicketDesk.

Option A:
The first would be to have each web site instance manage it's own schema within the DB. Each site would use a different SQL schema, and most likely each schema would be owned by a different SQL login. This would result in one database that has a several copies of the database tables, one set per tenant.

Pros: Data is physically isolated per-tenant. Though the DB server's resources are shared among all tenants, the individual tables contain data for only a single tenant. It is fairly simple to move a tenant to another SQL DB or SQL server later. The chance of accidental data pollution between tenants is low.

Cons: Requires advanced SQL concepts such as multiple logins, table access permissions, and schemas, etc.
Option B:
Single schema supporting multi-tenant at the row level. Here, you only have one set of tables, and one login (like it has now), but each table would include a tenant ID column that identifies the tenant to which each record belongs. Each instance of the site simply includes its own Tenant ID as a parameter for all SQL queries.

Pros: This is a simpler approach to multi-tenancy from both a code and a database configuration point of view.

Cons: All tenant data is physically stored in the same set of tables, so performance can become an issue as the database grows. The chance for accidental data pollution is higher.
I have considered supporting full multi-tenancy with TD3 at both the web site and the DB --each site hosting multiple tenants, with one or more multi-tenant capable databases. After spending a bit of time designing it though, I decided that it would only make sense in a paid premium version of TicketDesk, or a cloud hosted subscription version. The infrastructure, support, and configuration issues that come along with that sort of multi-tenancy are fairly large, while the added complexity adds no value for environments that aren't planning to use multi-tenancy.
Oct 20, 2014 at 11:57 AM
And the TD 2.5 is coming soon because I'm looking for the multiple projects feature ?
Nov 1, 2014 at 6:19 PM
TD 2.5 is in heavy development right now. A beta release of TD 2.5 is likely in mid to late November 2014, with a stable release sometime in December.

I had indented to be in stable release in November, but found that getting search and email to work in web-farm and Azure deployments required a different approach than I'd used in TD 2.1. I've worked out how to approach that problem now, but it did put me a couple of weeks behind schedule.