Being a relative newcomer to both XML and relational databases I too find them annoying.
In my case this is because I do not as yet fully understand their mechanics and as a result I am irritated at not being able to do what I would like to do.
However I doubt that that is the reason for your feelings.
I would be interested to know why you feel XML and relational databases to be "annoying and counterproductive".
| [reply] |
You missed a word.
It is the hype that that is annoying and counter productive. Not the technologies, which are generally perfectly sound when used appropriately. The problem comes when they becomed hyped to the point that all data has to be stored in a RDBMS; and whenever anything isn't in a DB, the file must be XML.
You arrive at the point where people starting stuffing binary object--images for example--into RDBMSs. Despite that they are entirely opaque to relational logic when stored this way devoiding the primary benefit. Despite that RDBMSs are usually pretty inefficient at storing and handling blobs.
And you end up with programming languages for performing manipulations of XML, written in XML. Ie. XSLT and XPATH. A program that can be written as a one-liner in Perl becomes ten screens of tortuously clumbsy, grossly inefficient and nightmarishly opaque code. Eg. Take a quick peek at this and try and work out what it does? And if you succeed in getting a clue to it's purpose think about how much easier it would be to read if it were written in Perl. Or just about any other language.
The blanket application of any technology is questionable. OO is very powerful, but somethings are just more easily abstracted and manipulated using a functional techniques. Perl 5's sort is the very essence of how powerful procedural techniques can be. One routine that can be used to sort almost anything in almost any way imaginable.
Sure, you could add a sort method to arrays; and a sort method to hashes; and sort method to lists; and all of those could call the underlying single sort routine so as to make things look OO--but it would just be a facade of OO-ness. According to OO-doctrine, it would be necessary to inherit the sort code from some superclass, but what would that superclass be?
The latest invention is variously called mixins, traits or interfaces (though the latter is somewhat different). These can (in some circumstances) be viewed as dataless objects. The reality is that they are just collected groups of subroutines. Ie. Procedural code.
Problems always arise when you try to force fit the universe into a single, coherent model. The debate, and much of the effort gets moved away from 'solving the problem' to that of 'how to solve the problem of solving the problem'. So much time and energy is wasted wrapping up simple, non-conformant solutions into complicated conformant wrappers.
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.
| [reply] |
The problem comes when they becomed hyped to the point that all data has to be stored in a RDBMS; and whenever anything isn't in a DB, the file must be XML.
Ah, but what about native XML databases? Now there's hype for you, and you don't ever need to store data in files again!
Talking about opaque data, take a look at the mzXML file format. It's a way to store several mass spectrometry runs in a single file, including the parameters of the mass spectrometer, any extra processing done on the data, and other sorts of metadata.
Mass spectrometry data, since it's, in some sense, a sampled analog signal, consists of floating point pairs with the first number being the mass value (or rather the mass to charge ratio, but this is not important here) and the second the intensity for that mass value.
Now, the designers of the format had more clue than simply stuffing this in the following rather straightforward XML:
<peaks>
<peak><mass>100</mass><intensity>1240</intensity></peak>
...
</peaks>
(That would be a nightmare!) Instead, they defined that everything else except peak data is structured metadata in the normal XML style, making a DOM tree, and the peak data itself is stored in a base-64 encoded string in IEEE floating point format in network byte order. So, what you have in the file is, in the case of raw data, a few dozen kilobytes of metadata, and then 130 megabytes of binary junk that is completely opaque to any human being.
While it is generally speaking laudable that people try to make common file formats for storing mass spectra -- as usual, all mass spectrometer manufacturers have their own file formats -- they could have just rolled their own file format without the burden of traversing DOM trees while parsing. I guess there were enough programmers in the bunch who were just thinking of the convenience of using standard XML parsing libraries...
| [reply]
[d/l] |
Apologies for I missing the "hype" aspect.
The explanation was very enlightening and I have learnt something new.
| [reply] |
