Side note about indexes.
This commit is contained in:
parent
4c136ddf82
commit
e903b9df43
@ -1,6 +1,7 @@
|
||||
.so macros.roff
|
||||
.de TREE1
|
||||
.QP
|
||||
.ps -2
|
||||
.KS
|
||||
.ft CW
|
||||
.b1
|
||||
@ -10,6 +11,7 @@
|
||||
.ft
|
||||
.fi
|
||||
.b2
|
||||
.ps
|
||||
.KE
|
||||
.QE
|
||||
..
|
||||
@ -387,7 +389,6 @@ As with other indexes, once the tag is requested to the database, every new or m
|
||||
.KS
|
||||
Let's imagine having two cars with different associated keywords.
|
||||
.TREE1
|
||||
.ps -2
|
||||
$ tree db-cars/
|
||||
db-cars
|
||||
+-- data
|
||||
@ -400,7 +401,6 @@ db-cars
|
||||
`-- fast
|
||||
+-- 0000000000 -> 0000000000
|
||||
`-- 0000000001 -> 0000000001
|
||||
.ps
|
||||
.TREE2
|
||||
.QP
|
||||
Listing all the fast cars is simple as a
|
||||
@ -411,7 +411,20 @@ directory!
|
||||
.QE
|
||||
.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
|
||||
.SECTION Limits of DODB
|
||||
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
|
||||
.B "stupidly"
|
||||
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.
|
||||
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
|
||||
.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
|
||||
.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
|
||||
.I indexes ,
|
||||
as for SQL databases.
|
||||
|
Loading…
Reference in New Issue
Block a user