[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-devel
Subject:    Addressbook Database
From:       Mike Pilone <mpilone () slac ! com>
Date:       1999-04-06 13:32:08
[Download RAW message or body]

Hello All,

I have been watching the posts fly by about what sort of database
implementation we should use for the KDE addressbook, and I found it kind
of funny. Mirko and I had this discussion about a month ago when I
started developing PeopleSpace and he was starting kab2. At that time we
posted to this list and no one seemed interested, now everyone has an
opinion! Not that I think that is bad, but I just thought I would let ou
know what Mirko and I decided. 

Kab uses a text base database
written by Mirko himself. This has the advantage of already supporting a
lot of the QT classes already and also it carries all the advantages of a
text based database. I'm sure you can find docs for it on upload.kde.org,
or contact Mirko himself. From what I know, it will load the entire DB
upon startup. This could be slow at initialization, but it then gives a
log N speed.

PeopleSpace was/is using gdbm. This is because I wanted to use a real
database as the backend. I felt this would increase the speed of the
program and probably be less buggy. I also chose gdbm because it was/is
already included in the kde distribution. I wrote some simple interface
classes and also a DBEntry object. This allowed a program to just request
any entry from the database and the db would return a DBEntry. The
application could then use the DB entry however it wanted. For example,
PeopleSpace my need 20 to 40 fields in the entry, whereas something like
Kab might only want 10 to 15. This means PeopleSpace would make a PSEntry
and it could swallow a DBEntry and grab all the fields needed. The same
with Kab, create a KABEntry and grab only the fields it wants. This allows
for the addition of fields in a DBEntry without effecting other programs
depending on it. The key<->entry link I used was that I set each entry to
start at a multiple of 100. This allows for 100 fields per entry. Also,
this allows to search the database by field. Like you can say that
lastname is key 1. So to search by last name you would just look at key
101, 201, 301, 401, 501, ... This also means that there is no overhead.
Even though I am searching the database by individual fields, I never load
the db into memory. PeopleSpace uses this feature by creating a QListView
of first/last names, then when the user selects a name, PeopleSpace then
(and only then) loads the entry from the database.

I am not saying that gdbm is the greatest, but it is already in the KDE
dist. I think that using an established database will give use some
significant advantages. Let the people who write the database worry about
time trials and different storage methods. All we need to do is use it.

Just MHO,
-mike

[prev in list] [next in list] [prev in thread] [next in thread]