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.
smime.p7s
Description: S/MIME Cryptographic Signature
