TABLES GLOBAL
|---- id ---- PRIMARY KEY | type: unsigned int | readonly (unable to change) | unique
|---- title ---- ONE | type: string [10, 100] | required
post ----|---- text ---- ONE | type: string [30, 10000] | required
|---- tags ---- MANY (means that can be shared with other entries) | type: string [2, 50] | required
|---- slug ---- ONE | type: string [5, 100] | required | unique
|----------------------------------table folder [%table%_stf]
| |
| [ pkvf ]
| |
| 1.101_pk, 102.202_pk, 203.303_pk, %n%.%n+CHN%_pk .... etc [index folders]
| (Each index have an related file as row data, chunks/CHN length defined by user, default 100)
| [ -= Description =-
| In fact PK files contains serialized array with index as key and row file as value
|
| each row that is related to pk entry is stored in sub folder, that is selected
| when table grow up to the value defined by the user (default 100). Row file
| name is equal to index value + static part, as |randstr|_rc, where |randstr| is random
|
| The name is generated as %n%.%n+CHN%_rcf where first part has the same values
| as for generating pk files.
|
| Note that incremental value of primary key is stored in incpkv file
| ]
|
|
[ ridxf ]
|
|---------------------|
|
|
|
|
%field%_ridxf (reversed index every field)
[ -= Description =-
Serialized %field% value MD5 hash as rev index file name.
There can be collisions, that's why an rev index file
will have multiple primary keys as value, if the is multi than each
index row is retrieved and raw values are compared binary until the first
full match occurs.
Note: if we have an MANY as relation key than some rows are returned
after binary comparison of values.
Sub folders are sha1 from first 16 bytes of MD5 hashed file name.
]
For more advanced searches would be used binary search tree located in [ bstr ] folder.
Search comparator should be defined for each field.
Search comparators tree nodes are located in %field%_bstrnds subfolder in a big bstrdf file...
NOTE: bstrdf should be chunked in the near feature
|
Download
