Le 2 oct. 06 à 20:46, Yen-Ju Chen a écrit :
On 10/2/06, Quentin Mathé <[EMAIL PROTECTED]> wrote:
At first sight, I don't think it's a really good idea to put
everything together, it's probably better to put each kind of object
in separate database.
It's true it could allow better search speed : it's faster to run a
single query on a single database than several ones.
For a system-wide search request, even if we don't reindex the
objects in this database with LuceneKit and we rather search both
LuceneKit index and this global database, the speed should be quite
good. If we have several different databases we will need to reindex
them in LuceneKit to keep a decent search speed.
I think it's not easy to tune the number of databases/indexes choice
in order to keep the best possible search speed in as many cases as
possible.
However we won't probably be able to avoid other databases for third-
party applications unless we decide to make this system database
open, but it could be rapidly screwed up by too many entries then.
I'm also really not sure CoreData has been designed to scale in such
important way (handling a bunch of schemas), this should be checked.
As a last note. The last time I checked it, GSCoreData wasn't totally
ready. We should ask Saso about it :-)
I will worry less about indexing and searching for now.
ok
So there is the concept I have:
Applications read and write through BookmarkKit,
which abstract the backend database.
Each application can has its own domain, just like NSUserDefaults.
And each domain can just be a database.
An indexer can just crawl through all databases for searching
later on.
BookmarkKit behaves as a manager for all the databases.
It is not hard to store the records in database one by one.
But we also need to store the organization of records as in my
second email.
In this way, BookmarkKit need another file, probably an NSArray,
to keep track which records belongs to which group.
Therefore, a complete domain in BookmarkKit contains a database for
all records,
and a property list for the group.
They can be put together in a bundle.
Does it look reasonble ?
I'm not really sure to understand, neither I make myself very clear.
My vision was the following one…
Either several databases (each one shared between all applications or
used privately by a single one) dedicated to:
- bookmarks
- contacts
- mails
- etc.
Bookmarks would be available to any applications through BookmarKit,
contacts through AddressesKit. But mails would be used privately by a
mail application.
Or instead of the three previous databases, just a single one where
the previous stuff (shared or private) is stored together :
bookmarks, contacts, mails etc. This is what I understood from your
initial plan when I read you first mail. I could be wrong though?
By reading your last proposal, I have the feeling you mention
BookmarkKit when in fact you think to some new framework unrelated to
bookmarks management or not restricted to?
If I understand your proposal correctly, I would say it's probably a
little bit complicated if you only consider BookmarkKit in this plan.
Having a single database by user for BookmarkKit is perfectly fine I
think.
And why not model group vs bookmarks (and other organisation aspects)
in term of relationship(s) rather than relying on an external
propertylist?… when you take in account CoreData or sqllite both have
relational support.
Do you have any particular reasons to split bookmarks storage in
several databases (one per application)?
Cheers,
Quentin.
--
Quentin Mathé
[EMAIL PROTECTED]
_______________________________________________
Etoile-discuss mailing list
[email protected]
https://mail.gna.org/listinfo/etoile-discuss
