XML is a powerful tool. Having the ability to store data in a text file using a method that resembles the way you would do the same thing with data structures and containers in code is a big deal.
Or, at least I see it that way. Before I heard of XML, every implementation of data storage or retrieval involved me writing up some code (hopefully cutting and pasting from some other similar program) and writing binary to the data files. This inevitably includes writing some sort of viewer program, which takes even more time. I am not one of those people who can look at a hex dump and see the blondes in the Matrix.
With XML technology, your text editor is your viewer. And it’s quite simple to think in terms of XML. I can visualize the database I need and the XML layout and support code is nearly already written in my mind, since the technique lends itself to hierarchies of data. Hierarchical databases are nearly all I use anymore, and that makes me wonder.
I tend to fall in that group of people who finds a new toy and proceeds to try to solve every problem with it. Just like the old Maslow’s Hammer: “if all you have is a hammer, everything looks like a nail.” I usually have lots of tools in addition to that hammer, but I use the hammer anyway. Because it’s new, and it rules.
I think I am falling into that trap with XML. I can’t really remember what I did for database design before I got the hang of XML. Now everything I come up with is a big top node that contains a series of nodes that themselves have a bunch of nodes, ad nauseam. So the software that parses that collection of nodes looks just like the XML: a map of the first tier, and then that tier is whatever container fits it best until I get to the bottom of the DOM tree and find that nugget of data I am looking for.
Are relational databases so far behind me? I think that I may need to step back sometime and think if XML is a good solution for everything (or perhaps anything). I am probably permanently infected; as soon as I typed relational database I tried to think how I would write XML that could describe a relational database. But those tend to be better stored in flat files, and I know a relational database can be described in XML, but relational databases are flat. Describing a relational database with XML is like putting tighty whities on a horse. Horses don’t need underwear, don’t like underwear, and they really stretch out the leg holes. How about a nice saddle?
The problem I am tackling is like this:
A Maze consists of Floors that each contain one or more Pieces, each of which consists of one or more Chunks, where a Chunk has various numbers of Rooms, Corridors, and Vaults. So I lay this out mentally in XML like:
<maze> <floor> <piece> <chunk> <corridor/> <room/> <vault/> </chunk> </piece> </floor> </maze>
It seems logical, and I know what attributes I need for each type of element, what data structures I would parse those XML elements and attributes into, and what containers would give me the fastest search times for each element type given how I will be using the data.
But I worry when I see a hierarchy in my mind these days. Am I just whacking the problem with my hammer? Maybe there is a crowbar around here somewhere…