cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Donald Ball <ba...@webslingerZ.com>
Subject Re: xBug
Date Fri, 21 Jan 2000 03:46:39 GMT
On Thu, 20 Jan 2000, Jerm wrote:

> Dear All,
> 
> I have been in discussion with Stefano over the last couple of days, about
> building a Bug Tracking system for Cocoon, in Cocoon.
> 
> After going over various ways of handling this, we decided that the only
> technique that really makes any sense, is to store bugs in an SQL Database.

I dunno, I take some issue with this. Yes, I wrote the current version of
the SQLProcessor (and am working on the taglib version), but I'm not
necessarily the SQL advocate. I think you should only mess around with
storing data in a SQL database instead of in an XML file if there are an
insane number of entities to be stored (more than a few hundred to a
thousand, depending on the complexity of the entities), or if your
commonly performed queries are complex and performance is really critical.
For most things, I'd much rather put the data into an XML file (or a set
of 'em) and use XSLT (and by extension, XPath) to extract and render the
bits that I'm interested in. Writing complex SQL queries, or even worse,
writing logic to write complex SQL queries, is much more painful IMHO.

Furthermore, it's much easier to add, uh, special case data fragments in
XML than it is in SQL. For instance, suppose you decided that each bug
report would be assigned to single designated fixer, but then you ran into
a bug that needed to have two designated fixers. In XML, you'd just add
another <fixer> to the <bug>, but in SQL you'd either have to add a series
of columns to the bug table (e.g. fixer2_name, fixer2_email) or you'd have
to move the fixer information to a foreign table and then put a reference
to the foreign table in the original bug table and then rewrite all of
your queries that reference fixer to do the lookup into the foreign table.
Ick.

Naw, for the number of bugs per project I think we'll have (several dozen
to a hundred?) I can't see any reason to go through the trouble of messing
with SQL. Plus it'd give us some valuable experience working with largish
XML datasets. I wrote SQLProcessor to give myself a bridge to 'legacy'
data, and to access datasets that I simply couldn't work with as straight
XML (e.g. databases with thousands of articles with thousands of words).

Perhaps I am missing some compelling reason to choose SQL for this app
though? If so, I'd love to hear it.

- donald


Mime
View raw message