My customers have single or multi-user Progress Database licenses. The database is in-house and not cloud based. Users logon to the application and their credentials are checked against an employee table (logonName , password).
I haven’t studied the new tenant enabled database possibilities yet but given a db schema with tables such as Customer, Sale, and Saledetail, could I offer a feature where the customer table is shared and depending on a users logon credentials (domain), isolate sale and saledetail data?
So, if a customer has a single OR multi-user Progress database license they could compartmentalize the transaction data by TenantID for reporting purposes, and share a set of common tables such as customer, vendor, and the usual assortment of supporting attribute tables (state, zipcode, transType, etc).
The offer would be something like -
Keep 10 separate sets of books in one environment that share your customer and vendor records.
The answer is "yes" you can do exactly as you describe with the multi-user database. This is an envisioned scenario. This doesn't really make a lot of sense with a single-user database.
But, be aware of the current license restrictions on MT enabled databases. I believe it currently requires an enterprise DB license.
mbaker wrote:
The answer is "yes" you can do exactly as you describe with the multi-user database. This is an envisioned scenario. This doesn't really make a lot of sense with a single-user database.
But, be aware of the current license restrictions on MT enabled databases. I believe it currently requires an enterprise DB license.
MT isn't a "single user" or "multi-user" technology, it's a user authentication coupled with db data partitioning technology, so it can be used either way.
MT also requires an Enterprise license to run, so getting a WG license and adding MT to it is out.
In an OpenEdge 11 mulit-tenant database, you can designate some tables as shared and some as multi-tenant. Shared tables work just like they do in databases that are not multi-tenant enabled. All users have access to the shared tables, subject to the normal access control mechanisms (can-read, can-write, etc.). The main purpose of shared tables is precisely for uses such as those you describe. Mullti-tenant tables are partitioned by tenant. A user that belongs to a particular tenant can see only the data in their partitions and shared tables. You can think of it as though each tenant has their own private database and a connection to anoher database that is shared by all.
As with everything else, there are some things you have to be careful about. I would suggest that as a matter of practice, for regular tenants,
I say this knowing full well that exceptions will be necessary. When they are, you should know why you need to make an exception and have a good reason for it.
Another thing you should do is avoid foreign keys that go from shared tables to multi-tenant tables.
In my target marketplace (retail firearm dealers), an FFL (Federal Firearm License) holder must comply with strict federal laws, and his premises are audited frequently. He must keep accurate acquisition and disposition records. My software does this for a single FFL. There are several types of FFL, and a single person can hold more than one license.
I was thinking, wouldn't it be great to offer a feature for these multi-license holders where sales and acquisitions could be partitioned, yet customers and vendors remain shared. My customer, the user of the software, would just switch domains depending on what he was selling or purchasing or reporting on.
My thinking was that it might be possible to do this with no schema or code changes, offer it with a personal db license, and limit the partitions (10 pre-configured).
I'll have to think of another way to do this.
Thanks to all for clearing this up for me.
It may be possible to do what you want by going to a percent-of-application agreement with PSC. This way, instead of paying a per-seat (or what-have-you) license cost, you pay PSC a percent of some sales amount, and they give you access to the technology you need.