Side note about indexes.

This commit is contained in:
Philippe PITTOLI 2024-05-16 15:23:19 +02:00
parent 4c136ddf82
commit e903b9df43

View File

@ -1,6 +1,7 @@
.so macros.roff .so macros.roff
.de TREE1 .de TREE1
.QP .QP
.ps -2
.KS .KS
.ft CW .ft CW
.b1 .b1
@ -10,6 +11,7 @@
.ft .ft
.fi .fi
.b2 .b2
.ps
.KE .KE
.QE .QE
.. ..
@ -387,7 +389,6 @@ As with other indexes, once the tag is requested to the database, every new or m
.KS .KS
Let's imagine having two cars with different associated keywords. Let's imagine having two cars with different associated keywords.
.TREE1 .TREE1
.ps -2
$ tree db-cars/ $ tree db-cars/
db-cars db-cars
+-- data +-- data
@ -400,7 +401,6 @@ db-cars
`-- fast `-- fast
+-- 0000000000 -> 0000000000 +-- 0000000000 -> 0000000000
`-- 0000000001 -> 0000000001 `-- 0000000001 -> 0000000001
.ps
.TREE2 .TREE2
.QP .QP
Listing all the fast cars is simple as a Listing all the fast cars is simple as a
@ -411,7 +411,20 @@ directory!
.QE .QE
.KE .KE
. .
.SECTION A few more options .SSS Side note about indexes
DODB presents a few possible indexes (basic indexes, partitions and tags) which respond to an obvious need for fast searches.
Though, their implementation via the creation of symlinks is the result of a certain vision about how a database should behave in order to provide a practical way for users to sort the entries.
The implementation can be completely changed.
Also, other kinds of indexes could
.B easily
be implemented in addition of those presented.
.TBD
.
.
.SSS Cached indexes and ram-only indexes
.TBD
.SECTION DODB library: all the important parts
.TBD .TBD
.SECTION Limits of DODB .SECTION Limits of DODB
DODB provides basic database operations such as storing, searching, modifying and removing data. DODB provides basic database operations such as storing, searching, modifying and removing data.
@ -455,19 +468,27 @@ DODB will provide some form of atomicity and consistency at some point, but noth
The whole point of the DODB project is to keep the code simple (almost The whole point of the DODB project is to keep the code simple (almost
.B "stupidly" .B "stupidly"
simple). simple).
Thus, managing or not these properties isn't a limitation of the DODB approach but a choice for this specific project. Not handling these properties isn't a limitation of the DODB approach but a choice for this project\*[*].
.FOOTNOTE1
Which results from a lack of time, mostly.
.FOOTNOTE2
Not handling all the ACID properties within the DODB library doesn't mean they cannot be achieved. Not handling all the ACID properties within the DODB library doesn't mean they cannot be achieved.
Applications can have these properties with a few lines of code. Applications can have these properties, often with just a few lines of code.
They just don't come They just don't come
.I "by default" .I "by default"
with the library. with the library\*[*].
.FOOTNOTE1
As a side note, the
.I consistency
property is often taken care of within the application despite being handled by the database, for various reasons.
.FOOTNOTE2
. .
. .
. .
.SECTION Experimental scenario .SECTION Experimental scenario
.LP .LP
The following experiment shows the performance of DODB based on quering durations. The following experiment shows the performance of DODB based on querying durations.
Data can be searched via Data can be searched via
.I indexes , .I indexes ,
as for SQL databases. as for SQL databases.