Proposal: Encouraging DB-using applications

[Daniel Stone]

On Sun, Sep 21, 2003 at 10:54:35PM +0200, Guillaume Laurent wrote:
> On Sunday 21 September 2003 20:48, Roberto Alsina wrote:
> > What item trackbacks to what other? What items come from the same source,
> > or the same day. You can "display latest items" or "items for that day",
> > or many other combinations. Really, I think I have about 35 different SQL
> > queries, none terribly hard, but I have no idea how to do them using a
> > flat file.
> 
> So you need something a bit more complex than a flat file. But I really doubt 
> you need something like SQL.

So flat files don't always cut it?

> > The KRecipers author mentioned that often people have thousands of
> > recipes. He was complaining that a relational DB was too slow,
> > imagine a flat file :-)
> 
> Several flat files if you want. Come on, I can find | xargs grep through the 
> 150KLOCs of Rosegarden in seconds. And recipes are fairly short bits of 
> texts, you could probably even load the whole bunch in memory if you really 
> have to.

On a fast box (like my AthlonXP 2400+, for example), sure. On a slower box? Good
luck.

You're also assuming that people just dump recipes in as flat files. What if I
want to say "I have trout fillets, bacon, artichoke hearts, breadcrumbs, mint,
sour cream, lemon, and I want to cook something that takes under two hours, all
up"? Flat files aren't much use there - you'd need XML to do it in a flat file,
and *no*. DOM implementations are still far, far too slow to do it at any
resonable sort of speed, unless you have a G5.

> > SQlite is pretty reliable. Besides, saving a daily dump is trivial.
> 
> No, saving a daily dump is *not* trivial. This is exactly the kind of thing 
> which we too often regard as "trivial" but generate most of the problems. A 
> typical user will not know how to do that and will not want to learn. The 
> program will have to do it transparently for him, reliably, which means 
> things like checking the dumps are ok and you can load them back if you need 
> to. There are weeks of coding and testing behind this "trivial" thing.

Yes, but if it's all done in the name of making things faster, easier, and more
functional, then I'm all for it. I don't agree with your "weeks" assessment,
either, FWIW.

> > In some cases, it will. But sure, there are cases when a DB is not
> > necessary. I can tell you, trying to write a serious RSS aggregator
> > without one is much more difficult.
> 
> Then use sqlite if you really have to, but in things like knotes or krecipes, 
> it's over-engineering.

It's certainly not over-engineering for KRecipes - people do more than just look
up a text file for a specific recipe. Have a look at some of the commercial
recipe apps on Windows some day - they're not just a bunch of text files.

> > They are probably DB managers, or somesuch? We are talking embedded
> > DBs, it's not the same thing.
> 
> OK, I'm willing to admit these are easier to handle than postgres & friends, 
> but I don't think it's worth adding in kdelibs.

I am personally all for adding embedded DB support in kdelibs.

-- 
Daniel Stone                                              <daniel at fooishbar.org>
http://www.debian.org - http://www.kde.org - http://www.freedesktop.org
"Configurability is always the best choice when it's pretty simple to implement"
  -- Havoc Pennington, gnome-list
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 240 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20030922/aa28aee3/attachment.sig>