Proposal: Encouraging DB-using applications

[Roberto Alsina]

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

Well, making it use sqlite (admittedly, through python's sqlite module,
not qt), actually reduced the amount of code in the app, as compared
with a BDB-based version (which should still be shorter than a flatfile
one), and made it clearer (but that's subjective).

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

Sure. But again, what exactly is the gain in using a collection of greps
and basically reimplementing querying in the app? And if in the future you
need to change the queries you make, half the time you need to change the
layout of the files.

>> SQlite is pretty reliable. Besides, saving a daily dump is trivial.
>
> No, saving a daily dump is *not* trivial.

Actually, it *is* trivial. I do it transparently from the same app.
Every hour or so, it dumps its database in a background thread. The user
never sees it.

> A
> typical user will not know how to do that and will not want to learn.

He doesn't have to.

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.

No. It's one function call. If the DB was corrupted it would fail (I
think, I have never seen one that actually got corrupted).

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

KNotes, probably.

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

Whoa, thanks! ;-)

> but I don't think it's worth adding in kdelibs.

Why? I mean, sure, you say, and I agree, that there are many many apps
that don't need it. That's not an argument. There are many many apps that
don't need pasive popups, either.

What we seem to disagree on, really, is that you apparently believe that
databases are useless, and that no program whatsoever that anyone can ever
want to develop for KDE can need one (ok, I exaggerate slightly ;-).

If that's your opinion, I agree to disagree with it, because I don't think
I can convince you.

In any case, maybe the spirit of the proposal was not clearly expressed:
I want people to start writing apps for KDE that they are not writing now,
because the current state of DB support is too difficult to manage, and
it scares them (as it seems to scare you, a little ;-)

Now, your position is that there is no such app to be written. I gave a
few examples, Andras mentioned one. Those apps do exist.

Is including qsqlite (or something else, ok, I am not married to anything,
we can all start using a XML non-relational whatever, makes no difference)
worth it? Cost/benefit analysis:

Costs almost nothing. It's tiny. It's written. It's 1200 lines. How buggy
can it be? ;-)
Benefits: you say none. I say some.

Decision: not mine.

I have nothing else to say in this thread, really :-P

-- 
 ("\''/").__..-''"`-. .         Roberto Alsina
 `9_ 9  )   `-. (    ).`-._.`)  ralsina at kde.org
 (_Y_.)' ._   ) `._`.  " -.-'   KDE Developer (MFCH)
  _..`-'_..-_/ /-'_.'
(l)-'' ((i).' ((!.'             Buenos Aires - Argentina
Imminentizing the eschaton since 1971.