Database Reference
In-Depth Information
9
,
12
,
15
]. All of these seven multi-tenant database schema techniques are based on
traditional RDBMS [
5
,
17
]. Moreover, we describe the storage model design of
SalesForce and discuss its special programming and query languages. Furthermore, we
discuss some of the limitations of NoSQL (Not Only SQL).
The Private Tables technique allows each tenant to have his own private tables,
which can be extended and changed [
1
,
2
]. Using this multi-tenant query technique can
be transformed from one tenant to another by renaming tables, and metadata without
using extra columns like
data. In
contrast, many tables are required to satisfy each tenant needs. Therefore, this tech-
nique can be used if there are fewer tenants using it, to produce suf
'
tenant_id
'
to distinguish and isolate the tenants
'
cient database load
and good performance [
2
].
The Extension Tables are separated tables joined with the base tables by adding
tenants
columns to construct logical source tables [
1
,
2
]. This technique has been
adapted from the Decomposed Storage Model that splits up n-column table into n
2-column tables joined using surrogate keys [
1
]. Multiple tenants can use the base
tables as well as the extension tables [
9
]. This technique is considered superior to the
Private Tables approach described above. Nevertheless, in this approach, the number of
tables increases with increasing number of tenants, and with the variety of their dif-
ferent business requirements [
1
].
The Universal Table is a table that contains additional columns of the base
application schema columns, which enable tenants to store their required columns. It is
structured with two main columns
'
, and other generic data
columns, which have a flexible VARCHAR data type in which different data types with
different data values can be stored in these columns [
1
,
15
]. It is a flexible technique
that enables tenants to extend their tables in different ways according to their business
needs. However, the rows of the universal table can be too wide with an overhead in
the number of NULL values, which the database has to handle [
1
].
In the Pivot Tables technique, the application maps the schema into generic
structure in the database, in which each column of each row in a logical source table is
given its own row in the Pivot Table. The rows in the Pivot Table comprise of four
columns, including tenant, table, column, and row that speci
'
tenant_id
'
and
'
table_id
'
es which row in the
logical source table they represent. As well as a single data type column that stores
the values of the logical source table rows according to their data types in the desig-
nated pivot Table [
1
,
9
]. For example, the Pivot Tables can have two pivot tables, the
rst table
'
pivot_int
'
to store INTEGER values, and the second table
'
pivot_str
'
to store
STRING values. The performance bene
ts are achieved by avoiding NULL values and
by selectively reading from smaller numbers of columns [
1
].
The Chunk Table is another generic structure technique that is similar to Pivot
Table. Except, it has a set of data columns with a mixture of data types that replacing the
column
'
'
'
'
column in the Chunk Table. This technique
partitions the logical source table into groups of columns. Each group assigned to a
chunk ID and mapped into an appropriate Chunk Table. This technique has four
advantages over Pivot Table. (1) Reducing metadata storage ratio, (2) reducing the
overhead of reconstructing the logical source tables, (3) reducing the number of col-
umns, and (4) providing indexes. This technique is flexible, but it adds complexity to the
database queries [
1
].
col
in the Pivot Table with
chunk
Search WWH ::
Custom Search