Proposal: Encouraging DB-using applications

[Daniel Stone]

On Mon, Sep 22, 2003 at 04:15:13PM +0200, Guillaume Laurent wrote:
> On Monday 22 September 2003 03:45, Daniel Stone wrote:
> > So flat files don't always cut it?
> 
> Of course not. They do _most of the time_ for a typical desktop usage.

So why remove functionality globally, when it has practical application?

> > > 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.
> 
> Yes you can. Try it.

I used to maintain a database of around 1500 recipes on a P166. It hurt.

> > 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"?
> 
> First of all, I'm not assuming anything, in this particular case I know from 
> direct experience (my mother has been in that branch of business for years). 
> That use case you made up hardly exists in practice.

I use it all the time. Professional chefs and such don't use it much, but I can
assure it's very much used among enthusiasts (myself and my friends often find
ourselves in that situation, ditto family members). But we've gone too far into
the semantics of recipe-finding than database libraries, IMO.

> Second, yes, you very easily can do that through plain text files, and get 
> perfectly decent response times to such a query even on a P90 with 10.000 
> recipes. Do the math, at a 2KB per recipe (which is a very generous 
> estimation), it's 20Mb to grep through. A P90 will do that in seconds.

The reason you can't do it through flat files, is because 'grep' doesn't cut it
for complex queries like "under 2 hours preparation time", or given quantities,
or whatever.

> > Flat files aren't much use there - you'd need XML to do it in a flat file,
> 
> There are other ways to structure data than XML, you know.

Most of which are close enough to databases to not be 'flat files' anymore.

> > Have a look at some of the
> > commercial recipe apps on Windows some day - they're not just a bunch of
> > text files.
> 
> That doesn't mean it can't be done with just a bunch of text files (something 
> which, BTW, no Windows app ever does : it's primarily a cultural problem, not 
> an implementation one).

I don't see why it shouldn't be done with a DB. By the time you get all that
functionality in a flat file you've duplicated so much code it's useless.

> On Monday 22 September 2003 03:36, Daniel Stone wrote:
> > "But CPU power is cheap these days" does not hold water, and is
> > not a valid excuse. Instead, it should always be taken to expose the real
> > underlying reason: lazy developers.
> 
> Oh please, spare us the clich?s.

The best cliche among that paragraph was "But CPU power is cheap these days". It
is, sure. But with two large catches: a) in *RELATIVE* terms (relative to, say,
a CD player at $au35, decent CPU power is still hellishly expensively), and b)
that assumes people are buying it. There's no excuse for locking out a segment
of our target market. If you want to write lazy code that takes 100 cycles
longer for every op, fine, but please keep it out of kdelibs/kdebase (and
preferably KDE altogether).

-- 
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/20030923/3dff35df/attachment.sig>