On Saturday 02 February 2002 03:56, J�rg Walter wrote: > On Friday 01 February 2002 20:39, you wrote: > > That's the opposite of my experience, is all I can say. Under load MySQL > > becomes flaky as anything. It's thread management sucks, its query > > optimisation sucks, and when it goes down, it goes down hard. > > That's again opposite of my experience. I've recently tried to setup a > 20-30GB table in a database, which was a pain since the OS (Sun Cobalt's > Linux) didn't support files > 2GB and wasn't upgradeable. pg was totally > uncooperative at management (I never used it before, but all in all it took > longer than my first MySQL experience), and finally was out because of > speed. That box is as under-sized as can be, but I had no choice, so I did > it in MySQL with the latest table handlers. The result: It's definitely > faster than pg, it's faster at write access than MySQL's default table > handler, it even takes less space, and it's rock solid, even on this > overloaded, small-memory, small-processor, 50 vhosts, fscking Cobalt RaQ. > (Thats about > 1.000.000-1.500.000 rows in that one table) > I like it. And no, I never used triggers and suchlike before, I use MySQL > where it's best at: data repository, not application logic. > > Btw, I'd like to hear more DB experiences, as it definitely touches our all > work one day or the other. How did you serialize XML to a db?
Well, there are a BUNCH of solutions for moving data back and forth between XML and an RDBMS. XMLtoDBMS and DBMStoXML (the xml-dbms project) is an open source tool (written in Java, but there is a version in perl as well) that lets you build a "map" (which is like an XML Schema more or less) that defines the way the XML and database relate. Its pretty good for transferring data back and forth where the information is highly relational, or in cases where you want to export from one database and import to another. There are a number of similar commercial tools as well. Naturally you can also write your own tools as well from scratch for specific needs (performance mostly). Now, in cases where you have data that is not really very easy to represent in a relational schema, but you need to search it efficiently, or where the XML is irregular in form or subject to a lot of change you could put a few key attributes into seperate columns and store the rest of the XML as raw text (or even store the entire XML fragment/document as text and duplicate a few key tags/attributes to key on as seperate columns). You could also serialize DOM trees and store those in blobs. It all depends on your application. The thing is all these schemes can be hard to maintain. There are also non-relational data storage technologies you might look at. I've played around a good bit with an OO database called "goods" (there are others out there, some are hybrid object-relational). It has a binding to perl. Basically it lets you store perl hashes (which can be blessed) including hash and array refs into a database that has transactions, locking, etc. Because its client-server you could even use it as a form of shared memory for mod_perl based applications. It wouldn't be too tough to serialize XML to it. Unfortunately goods doesn't deal with circular references, which DOM trees ALWAYS have (because there are refs pointing to children and they have refs pointing back to the parent), but a serializer/deserializer could be designed to get around that problem. Other strategies would include building tools that translate XPATH specifiers or some form of XQL into SQL statements (some work has been done on this), though performance is always an issue there since you're basically taking one query language, making another out of it, then putting THAT through some form of engine that translates down to ISAM operations (this is how SQL databases operate). I guess the answer is there can be some general tools built to support this sort of stuff, but its still necessary to look at things on a case-by-case basis to determine the best approach. If you have a big budget you can get toolsets from Oracle or Microsoft that can produce good results in a lot of cases. Maybe AxKitB2B will move in the direction of providing support for that kind of thing. I'd definitely advice Matt or someone to have a good look at the perl version of xml-dbms as something to either support or model on. The guy that wrote it is pretty sharp and has a good group of developers, but they are mostly working in Java unfortunately. Hope thats helpful! --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
