FAQ: blockchain technology in bSQL
Tags: sql, database, datascience
Published: 2021-09-07 17:24:15

## Intro
The [bSQL](https://bsql.org/) language by [Blockpoint Systems](https://blockpointdb.com/) is a SQL for interfacing with immutable data. bSQL is not a decentralized blockchain, neither is it a traditional database management system. This resource is meant to provide and explanation of "blockchain" in bSQL.

## How is this blockchain?
The blockchain storage structure is the foundation of data storage in bSQL. This doesn't change the fact that bSQL is a centralized database management system. All data in bSQL is stored in centralized blockchains within a single machine. 

Built-in blockchain storage provides an additional layer of security without compromising data privacy. A blockchain implementation is more secure than traditional systems and provides the following benefits.
- **Prevents Illicit Changes from Inside Employees**: Users cannot update or delete physical data.
- **Detects Illicit Hacker Changes**: Blockchain detects changes to data by storing a cryptographic digest.
- **Detects Authority Ordered Illicit Changes**: MDB digests can be freely distributed publicly. Cover-ups can be detected by comparing the published digest to the current contents.

## How do I use the blockchain-ness?
The blockchain aspect of MDB is abstracted from the database user. Every time you read or write blockchain hashes are verified. You can manually validate all hashes by running a [CHECK VALIDITY](https://bsql.org/docs/database/check-validity) command on the [master database](https://bsql.org/docs/master_database).

## What are the different kinds of blockchains?
Different [bSQL blockchains](https://bsql.org/docs/blockchain-overview) provide an interface-like method of interfacing with immutable data.
They optimize applications based-off of table / blockchain usage patterns.

- `HISTORICAL` &#8594; Optimized for historical data collection and logging. The historical blockchain is a bare-bone
  ledger optimized for fast insert speeds, large datasets, and non-primary key dependent data.

- `HISTORICAL PLUS` &#8594; Handles primary key dependent data and is optimized for infrequently updated data with inter-blockchain dependencies.

- `TRADITIONAL` &#8594; Provides traditional features such as primary and foreign keys as well as blockchain-specific attributes such as time series selection, validity, and lifetime tracking. This container was designed to manage relational data while providing fast access to mutation history.

- `SPARSE` &#8594; Provides the same functionality as a traditional blockchain but optimizes storage by only storing changed values.

## How do I determine which blockchain to use?
The table below illustrates the basic methodology for choosing a blockchain to fit your database needs.

| Blockchain | FREQUENT INSERTIONS | INFREQUENT INSERTIONS | FREQUENT UPDATES | INFREQUENT UPDATES |  
:--------------: | :---------------------: | :-----------------------: | :------------------: | :-----------------------: |  
| `historical`    |  :heavy_check_mark:            |                         | &#10005; | &#10005; |
| `historical(+)` |  :heavy_check_mark:            |                         |                  |:heavy_check_mark:               |
| `traditional`   |  :heavy_check_mark:            |  :heavy_check_mark:               |                  | :heavy_check_mark:               |
| `sparse`        |                     | :heavy_check_mark:                | :heavy_check_mark:          |                        |