|Pliant talk forum
Feature request: Suggestion of database implementation
Are databases still done only in memory.
I dont really use Pliant, but yesterday I was thinking
about a way to distribute a simple database program without
having people to setup the databases, and I began to think
about simple database implementation. And when it was
finished, I thought about pliant because I'm too lazy to
implement it myself and it looked in the spirit of
Pliant to me. Anyway current Pliant model would be enough
but I'd like my yesterday ideas be saved somewhere.
|Message posted by paduf38 on 2003/02/09 17:59:34
|Here are the big picture:
-this is a "network" database model, not relational, that is
it work with pointers to records
-tables are store in three files: table.head that contains title and type
of the fields, fields can be of fixed size or variable size, table.data
contains all fixed-length records, table.varsize contains all variable sized
data including relational pointers between records
-relations between table are seen like special variable size (varsize) fields
-a varsize fields in the table.data contains a pointer in table.varsize+
the lenght of the field
I will post the rest in an other message, because it is failing when it is too
|Message posted by paduf38 on 2003/02/09 18:05:22
|-modifying a varsize field: if the new size is smaller or equal to the
old one, just use the same place in table.varsize, if it is bigger, just
allocate the new place at the end of table.varsize, see next point for
-cleaning the table can be sometime done, by passing through all varsize
fields in table.data, and allocating all fields in a new table.varsize,
actually, this is rebuilding the table.varsize when too much stuff have
been deleted (deleted stuff are just not yet accessible stuff until this
cleaning is done)
-each relational fields header (in table.head) contains information on
the number of links to other tables, so as to be able to know the average
number of links by records, when creating a record, it will be created
with a varsize able to hold this average number of links by records pointers
to others records in othertable.data
|Message posted by paduf38 on 2003/02/09 18:06:20
|-The first information in a relational field (inside table.varsize), is
the actual number of links, all the pointers are following after this number
-When the actual number of links become too big for the size of the records,
a new record is allocated at the end of table.varsize, two times bigger than
the old one
-Deleting a record in table.data, is done by marking it as deleted, but
sometime, even the table.data need to be cleaned, this is a big task to
do, since all records linked to this record in other tables, need to have
their pointers fixed
-in table.head, information is there to know if we can delete records of this
database when a record of another database link with a record of this database
is deleted, that way, the database engine is able to know when to allow
cascade deleting, and where it can not
-all relations can be one-way or two-ways
|Message posted by paduf38 on 2003/02/09 18:09:15
|Well, this is the big picture. I'd like to have comments. Is it too
late for Pliant for having filebase databases, is this an interesting
|Message posted by hubert.tonneau on 2003/02/09 23:08:21
|There are several problems with databases stored on disk:
. it's not easy to write an efficient storage mechanism on disk that will
always recover gracefully from a crash of the process.
. the table notion tend to bring poor handling of most 1-n relations because
the sub records are too far from the main one.
. any server will require to store most of it's database in the disk cache,
so in memory, in order to bring decent performances.
Now about Pliant dabase engine:
. the huge advantage of Pliant database engine is that it's crash safe, and
automatically upgrading when the database structure changes (add or remove
some fields): in other words, it's self managed.
. it also has a 'split' mechanism that enables to have most of the datas of a
large database stored on disk.
. the huge problem is that loading from and storing to disk is slow because
the disk file format is ASCII.
So, the right way to extend Pliant database capabilities would be to add a
binary encoding for the database on disk (I mean trivial streaming), but the
problem with it is to properly deal with a change in the database structure.
When done, another way to extend Pliant database capabilities would be to
do smarter automatical splitting (remind that a Pliant database is a tree)
rather than the explit one.
I tend to believe that the table on disk vision, as opposed to the tree one,
is now obsolete.