As we deal with different kinds of data within BangDB, we need different methods which we use for these respective data types. Therefore there are multiple types of tables that we can create and use. These types are defined by enum bangdb_table_type
Following are different kinds of tables;
INDEX_TABLE, //opaque(void*) as key, datlen is of actual value in the data file store in main table
PRIMITIVE_TABLE_INT, //int as key and int as val, stored in index file only, no data file
PRIMITIVE_TABLE_LONG, //long as key and long as val, stored in index file only, no data file
PRIMITIVE_TABLE_STRING, //opaque(void*) as key and data stored in the index only, no data file - Fixed Table
Each of these table and their operations are explained in subsequent sections.
Note: In majority of scenarios, we will be working with WIDE_TABLE. When in doubt, we used simply select WIDE_TABLE as it provides richest set of operations. The document support is enabled only by WIDE_TABLE.
Also, LARGE_TABLE should be used when we want to store files, or large objects
Let's discuss now in detail, when to use what
When we wish to store key value, where value could be any text or opaque data (not of large size, i.e. beyond few MBs or so), then we can select this table.
Note: This table does not support secondary, reverse etc. indexes. It can only store data with primary index
You may think of this table as key / val nosql db
When we wish to store all kinds of data, including document data, and we also wish to create indexes then we should select this table type
This is mostly used by db itself in many cases for optimisation and performance, therefore if not sure, pls don't use this table type.
We will discuss when and how to use this in advanced section
All of these tables are more like single column table where the value is always fixed type. int, long, double etc.
The key could be of int, long and string type, and hence the last part of the name reflects that. These tables are super efficient from size in the memory or on the disk is concerned. Performance wise also it scales best. There are other optimisation done to benefit from the use case scenario
This is suitable for storing large files and objects. The size could run in several tens or hundreds of MBs or more.
This is internally used by the db for AI related files, models etc, storage.
Note: This table is part of r BRS (BangDB Resource Server, which is kind of S3 in aws. It exposes similar apis and also serve similar purpose without necessarily going over to cloud. Moreover, being a table allows us to do other things that are done for tables