Data Partitioning

There are many scenarios with which a given implementation can leverage the Broadleaf Commerce MultiTenant architecture.

The most common scenario is that each site maintains its own data.

More advanced scenarios are also supported but require more customization. A common example is for companies that want
it's member sites to all share portions of the product catalog (or content) that were centrally maintained.

Catalog / site data

Sites and catalogs are created to represent each tenant and the product catalogs available to that tenant. Each site can
have one or more catalogs associated. This allows for interesting tenant combinations where catalogs may be shared across
tenants.

Site-specific and global catalogs

As you can see in the Data Model for the multitenant module, many of the core Broadleaf tables receive
the CATALOG_DISC or SITE_DISC columns when multitenant is activated. These columns are what control
which data is available to which site.

For example, to restrict a certain product to catalog 1, you would have the CATALOG_DISC column for that specific product
set to 1.

When these discriminator columns have NULL values, that means that they are shared between all sites.

Entities such as Orders, Customers, and Content belong to a given site and are therefore discriminated
with a SITE_DISC.

Entities such as Products, Categories, and Offers can be shared across sites and are designated with
a CATALOG_DISC.

The Offer entity is somewhat special. It was anticipated that offers might need to be managed at both the Site and
Catalog level and so you'll see that the BLC_OFFER table has both a Site and a Catalog discriminator column.