Proposal: Encouraging DB-using applications

[Guillaume Laurent]

On Tuesday 23 September 2003 06:54, Daniel Stone wrote:
>
> > Of course not. They do _most of the time_ for a typical desktop usage.
>
> So why remove functionality globally, when it has practical application?

Adding stuff to kdelibs isn't free. In that case I don't think the need is 
important enough.

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

How much, really ? And how well wriiten was the application ? And would it 
really have improved things if you had put everything in a postgres db ?

> > 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).

Among enthusiast geeks, yes. :-)

> 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.

No, but to extract fields from a series of file which you can then process 
later on, it's quite good.

> > 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.

Come on :

Name: foobar
Ingredients: foo (1), bar (0.5)
Time: 2h
Recipe begin
put foo and bar in oven
wait 5mn
eat
Recipe end

> 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.

Even a simple DB has *much* more functionality than what you described.

> hellishly expensively), and b) that assumes people are buying it. There's
> no excuse for locking out a segment of our target market.

Yes, there is : We have very limited resources. And if that segment is "geek 
chefs", I don't think it's much of a problem.

> 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).

So where's your example-setting highly optimised code that I can look at ?

Anyway, to wrap this up : I still fail to see a compelling need for a DB 
access layer in kdelibs.

-- 
				Guillaume
				http://www.telegraph-road.org