gump-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <stef...@apache.org>
Subject Re: Gump Database
Date Mon, 01 Mar 2004 18:47:39 GMT
Adam R. B. Jack wrote:

>>Stefano Mazzocchi wrote:
>>
>>>For this specific problem, I would go relational.
>>
>>+1. Brain-dead and ugly solution like mysql ;)
> 
> 
> When I think about the answers I've received [and thanks for them] I wonder
> if folks are thinking more about the ugly/brain dead type problem of results
> tracking. I agree, that is fine to do relationally. [That is where this
> thread originated, so perhaps I unintentionally led the response.]
> 
> BTW: First, let me state for the record, I'm no fan of XML for XML's sake &
> don't wish to try to push it where it isn't useful. Also, everybody ought
> use relational databases (specifically those wonderful ones from Sybase,
> which also happens to have some awesome XML/XQL features, and allows joining
> XML and relational data.) Ok, my corporate pitch ;-) ;-) ;-) over...
> 
> I realize I was more interested in the XML metadata, and it's changes over
> time. The results are why folks invest in granting us/maintaining their
> project metadata. The metadata is a map (a graph) of the community, and some
> interactions [some, needs to be extended for more], and I was hoping some
> form of XML repository could somehow give us a time factor on that.
> 
> I might be looking for more than is there, I might be looking for too low
> level an assist, but I'd like to know if folks who used to depend upon X no
> longer do [change in one XML], and when most migrated away [multiple]. I'd
> like to know if a product was a 'huge hit' [multiple], and who was migrating
> to it [multiple]. I'd like to see which communities/groups (lamely, for this
> mail, based off  repository) were using something. I'd like to know details
> like this over time.
> 
> I could push this graph into a relational schema but I feel that would be
> very restrictive, and would pre-determine the benefits. I guess I can take
> deltas, or store historical copies of the whole metadata, but I feel I need
> some tool that is into analysing XML over time. Maybe I do need XINDICE, or
> something like it.
> 
> Again, feel free to correct me -- and/or express your gut feelings against,
> but my gut tells me I have a storage problem but I don't know the right
> tools for the store, or the query mechanisms.

Adam,

I think you are looking at the problem from the wrong angle: the use of 
the data.

While the question that you should be asking yourself is: what does the 
data look like? how stuctured is it?

 From where I stand, the gump metadata is highly structured and can be 
perfectly mapped in to a relational structure with reasonable effort. 
Also, given its structure, can be indexed precisely and thus queried 
very efficiently.

At that point, once you have the data in the database, you can start 
thinking about what to do with it. Dependency graph visualization, 
history of dependencies, FoG estimation, all of these are problems that 
will result in particular queries and particular use of the result set.

Gump data does not exhibit any of the properties that appear in the 
semi-structured of highly connected pseudo-digraph problem space.

For this reason, I see absolutely no reason to avoid using relational 
solutions. Also because they are, by far, much more solid and easy to 
interoperate with than any other DBMS model.

-- 
Stefano.


Mime
View raw message