Icon View Thread

The following is the text of the current message along with any replies.
Messages 1 to 3 of 3 total
Thread MultiTenancy and Database Replication
Mon, Feb 24 2014 5:21 PMPermanent Link

Eduardo

Avatar

Hi there,

I am user of DBISAM and planning to migrate to ElevateDB, trying to understand some aspects.

1) I need to write a new version of our ERP, and plan to go ElevateDB. However this time I am looking to be MultiTenant, that is, to have separation of data between companies, while it is running under the same software. IT can be achieved or by a field on each table´s key, or by separate tables/databases.

There is pros e cons in each. From IT is easier the separate databases. HOWEVER I need to somehow run conciliation reports. I am planning to use tools like FastReports. Each of these database is already MultiStore. This is applicable in cases where a holding group controls singles companies and also chains of stores. From the holding perspective it is interested in conciliation reports, they not see the details of chains, they see it as a single company. But for the management of the chain they need to see each store independently.

I am worried to have it all in one database. Changing the keys to be capable to handle the tenant. I could eventually have hundreds of companies, each one a tenant, making one big database.

How can ElevateDB can give me hand on this? If independent databases is there a way to run SQL that cross several databases? (of course the table structure and table names are all the same)

2) In case of using separated databases for each tenant, is it possible to have a central server where I have many tenants and each company with its own replica on the local server?

(I am only getting more familiarized with ElevateDB now, and I see much of DBISAM on it, so I can create many databases each one in separated folders. Then the replication schema can be different for each one)

Eduardo
Fri, Feb 28 2014 5:15 PMPermanent Link

Tim Young [Elevate Software]

Elevate Software, Inc.

Avatar

Email timyoung@elevatesoft.com

Eduardo,

<< There is pros e cons in each. From IT is easier the separate databases.
HOWEVER I need to somehow run conciliation reports. I am planning to use
tools like FastReports. Each of these database is already MultiStore. This
is applicable in cases where a holding group controls singles companies and
also chains of stores. From the holding perspective it is interested in
conciliation reports, they not see the details of chains, they see it as a
single company. But for the management of the chain they need to see each
store independently. >>

Use separate databases.

<< How can ElevateDB can give me hand on this? If independent databases is
there a way to run SQL that cross several databases? (of course the table
structure and table names are all the same) >>

Yes, you can specify the database name as part of the SQL:

SELECT * FROM <DatabaseName>.<TableName>

The only requirement is that the databases all be defined in the same
configuration, otherwise ElevateDB won't know how to resolve the database
names.

<< 2) In case of using separated databases for each tenant, is it possible
to have a central server where I have many tenants and each company with its
own replica on the local server? >>

Just to confirm:  you're wanting a situation where you have one master
server with a lot of separate databases for each company, and then each
company have a server with (possibly) separate databases also ?

Tim Young
Elevate Software
www.elevatesoft.com
Sun, Mar 2 2014 12:48 PMPermanent Link

Adam Brett

Orixa Systems

Eduardo,

I think you should have separate databases for the store-centric parts of the data. At the same time you might have some shared tables in a Shared or System db.

My system uses a "System" db for all shared data, and has customer data in the "Main" db. This is easy to manage in EDB and from Delphi the query components can call:

SELECT
 *
FROM System.SomeTable

or

SELECT
 *
FROM Main.SomeTable

You can even mix databases in the FROM and WHERE clauses.
Image