XML is semi-structured data in that it may follow a specification (styleshe= et), but is unstructured in its presentation as nodes can be optional, have= multiple occurrences, etc. An RDBMS, by virtue of strict typing and a scheme, is structured data. =20 If you truly have XML, then you really need a database that natively suppor= ts it or an object store IMHO.=20 Or just store the flattened files, as you mentioned :) -m Sent from my iPhone > On Jul 5, 2014, at 12:52 PM, "Harold Hallikainen" wrote: >=20 > Thanks for the quick response! The PIC32s are doing an HTTP Post of the > XML to the server. So far, I have 3 or 4 line PHP program that appends th= e > XML to a file and emails it to me so I can see that it's working. I've > started on having that PHP script parse the XML and pass to MySQL, but, a= s > I was setting up the tables in MySql, I got to wondering about just using > a flat file holding the XML. Though the XML is verbose, the file would > still probably be smaller than the MySQL file with its constant field > widths. Constant record size files are certainly easier to search, but it > still seems like a random record size file could be searched pretty > quickly. I'm thinking of a binary search where'd you'd read in double the > maiximum record size. There's guaranteed to be a complete record in there= .. > String search for the openting tag, then parse from there. But, as you > point out, PHP already has support for MySQL, and has functions to parse > the XML (XimpleXML, etc.). I MIGHTbe able to use the PHP XML parsing to > deal with the appended file I'm currently generating, but this is, I > believe, all read into RMA and then dealt ith there. Not super scalable. >=20 > Again, thanks for the ideas! Maybe I' back to MySql. >=20 > Harold >=20 >=20 >=20 >=20 >> Certainly stuffing the data in MySQL gives you great flexibility. It >> shouldn't be a big deal to write a PHP or Perl script to stuff the data >> into the database. This makes reporting a whale of a lot easier, too. >> It sounds as if you are already generating XML files. No reason you >> couldn't just suck the XML from the PIC into the database and eliminate >> the intermediate file. But I presume you have already sorted out the >> messy issues of not overwriting old files, etc. >>=20 >> If you aren't familiar with PHP think of it as sloppy C. It is a little >> easier to get to the database in PHP than C, mostly because PHP is >> interpreted so changes are quicker when you are sorting things out. I >> also believe PHP has a library to make parsing the XML simpler, although >> I haven't used that myself. >>=20 >> An easier (if not as elegant) solution is to convert the XML to SQL and >> suck it into the database through the command line interface. A little >> bit of bash and you can automate this on the crontab. >>=20 >> --McD >>=20 >>> On Sat, 2014-07-05 at 08:25 -0700, Harold Hallikainen wrote: >>> I have a bunch of pic32 systems posting xml to a server. I could have >>> the >>> server parse the xml and save the data in mysql. Another possibility >>> would >>> be to just append new xml to the old in a text file, then access the >>> data >>> in that file to generate reports. I like the simplicity of just saving >>> the >>> xml. I'd like to hear comments on this and suggested xml database >>> engines >>> to search the data. This is running on a centos system. >>>=20 >>> Thanks! >>>=20 >>> Harold >>>=20 >>>=20 >>>=20 >>> -- >>> FCC Rules Updated Daily at http://www.hallikainen.com - Advertising >>> opportunities available! >>> Not sent from an iPhone. >=20 >=20 > --=20 > FCC Rules Updated Daily at http://www.hallikainen.com - Advertising > opportunities available! > Not sent from an iPhone. > --=20 > http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive > View/change your membership options at > http://mailman.mit.edu/mailman/listinfo/piclist --=20 http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive View/change your membership options at http://mailman.mit.edu/mailman/listinfo/piclist .