I am very, much new to DB, I find some difficulty in understanding some terms as mentioned below pls help me to understand table

CodePudding user response：

I suppose you should have been bit more clear. This is pretty vague question. However, as i see from the image, it seems this is about BangDB and about different types of tables it supports. Here is bit detailed answer;

A. When user wishes to store key and value only, where key could be either long type of string type, whereas value could be completely opaque (text or binary etc) and when (obviously with opaque value) secondary indexes are not required then NORMAL_TABLE should be selected. This table mimics Key/Value store and provides simple put() and get() operations on it. Note the Key could still be arranged in sorted manner (using B linkTree) or randomly stored using hash (ExtHash) in BangDB. And if Key is arranged in sorted manner then scan() could also be used. This table type also provides highest throughput since database operations tend to be more atomic

B. Think of WIDE_TABLE as document store. This allows users to store json document, similar to other document databases like mongodb. Since we store json document here, therefore apart from arranging primary key, we can also define several secondary indexes for faster retrieval of data for queries involving other attributes. BangDB allows secondary indexes which could be arranged using BTREE (B linkTree). Further user can use complex key (secondary) structure for secondary indexes (btw, this could also be done for primary key), for example composite key (using two or more keys together) for some of the complex queries for efficient scanning of the table. BangDB also allows reverse indexes in this table type, therefore users can pick which attribute within the document to be reversed indexed (or all attributes ...), this enables text search on the table. Hence, in simple sense, when we wish to deal with json documents (json) then use WIDE_TABLE type

C. Index_Table is not explicitly available for users in the BangDB. Instead Primitive_Table is available for scenarios where value is always fixed type (such as long, double etc.). Using Primitive table here would save database extra pages that could be used for storing values, instead the index (primary) pages could be leveraged for the same, thereby reducing pressure on memory and IO etc.

D. LARGE_TABLE is like NORMAL_TABLE, except that here the value could be really large. For NORMAL_TABLE value size is limited (2 - 8 MB) whereas if we wish to store images, videos, ML Models etc. then users should leverage LARGE_TABLE here which efficiently stores the large files efficiently

The motivation behind providing different table types explicitly is to allow users to deal with different data types differently (in suitable manner) within the same database. This makes it easy for us to efficiently exploit the nature of the objects/values for efficiency and performance.

E. GRAPH Store/Table option allows user to deal with linked data where db could explicitly or implicitly (using BangDB Stream) store the triples (subject, predicate, object) in the graph table. Using Cypher query language, we can find interesting data stored in the Graph table.

I hope this explains a bit in detail. You can check more info about indexes in BangDB and also about table types in the dev section

I am author of BangDB and would be glad to answer more queries. However, request you to kindly be specific when you ask question and also provide some context so that we can answer better

CodePudding user response：

the image you share are the different types of tables you can create.

Normal_table: stores key/value

Wide_Table(the common one): stores all kind of data, its the one that everyone uses, so it's recommend to focus on the use of this one. How To Implement It

Index_table: its focus on optimisation and performance and works with the primitive_tables that are like indexes on SQL, really i never work with this one outside of experimental reasons

Large_Table: used internally, it's for storing large files or objects.