Slashdot Mirror
What Do You Know About Databases And XML?
Dare Obasanjo writes: "XML has become a pervasive part of significant
segments of software development in a relatively short
time. From file formats to network protocols to
programming langauges, the influence of XML has been
felt. I have written an
overview of XML schemas, XML querying languages,
XML-Enabled databases and native XML databases.
Below is a shortened version of the article." Obasanjo's original OODBMS
article
has been updated to reflect more of the disadvantages
between picking an OODBMS over an RDBMS.
You kind find more on OODBMS and their benefits here.
There was a good discussion on XML data bases on the XML-Dev mailing list, which is summarized pretty well by Leigh Dodds XML and Databases? Follow Your Nose.
Wow, this guy posts early but it looks good so he gets modded up. What a crock.
XML solves the interchange problem. By this, it is meant that XML allows two systems that do not share a predetermined data exchange protocol to share data. Thats it.
That is a VAST oversimplification. What if instead you had said "computers allow us to carry out a repeated set of instructions. That's it." Doesn't quite tell the whole story, does it? Nor does your kindergarten-level definition of XML tell the whole story.
Applications of XML to programming lang design (XSL) and other domains are largely a waste of time and won't last.
Hmmm.... And will the stock market rebound in the next six months? Will Jesus FINALLY return and lift the Believers up into heaven? Will it rain next Friday?
You can speak out of your ass all you like. Doesn't mean it's gonna happen. XSL/XSLT has been around for a while now, and its user base has only been expanding.
He's a moron, obviously has done nothing more than skimmed a few chapters in some cheap-ass Wrox text, and he gets modded up to 5. There is no justice, I tell you!
After several weeks of dealing with growing pains and general brokenness, my manager wisely decided to transition our systems back to a UNIX environment. I worked in the group that was responsible for this, and after obtaining source code to several of our accounting and inventory applications, we moved the operation over to a Linux 2.2 (Debian potato) system. Things have worked flawlessly since then, and the OODBMS and Java developers are long gone. The promise of an OO architecture was great, but it just didn't work out in the real world - Linux was the solution for us.
-CT
xml is an interchange format, not a storage format
Absolutely, positively agree. Not only is XML only an interchange format, but it only makes sense in some situations (for instance if we have an embedded piece of hardware that we have to communicate with, and we're communicating to it from a Windows box, and there is no shared common data encapsulation format, I'd greatly prefer XML (with XSD) vastly over Jimmy the Programmer making up his own data encapsulation format/documentation method/extraction system, but if I have two Windows machines running SQL Server and they're in a common security context and they'll never change, I'd use DTS or replication, not XML).
and MS SQL Server is seeing the same thing now that they've got the XML in theirs
The XML "in" SQL Server is surface fluff (I love SQL Server and I'm saying this as a good thing, not a bad thing). i.e. Some modules that'll convert an XML query to an underlying DB query, and the results back to XML, and some basic XML importing and exporting routines. This hasn't affected the underlying operations of SQL Server whatsoever.
Linuxfromscratch.com has a project that aims to automate the process of building your own linux setup storing configuration files in XML, read the intro page they propose you could go to a website and fill out a survey type form to define your system, which would create a configuration file that could build everything correctly. It sounds to me like a huge undertaking but if distros chimed in on this and contributed the tools and expertise they have in how to install a linux system automagically, Automated Linux From scratch could become a standard tool used by anyone wanting to setup linux on anything. To go one step further and convert my /etc directory to MPXML (My Penguin XML...I made that up) well I don't know if this would be a good thing.
"The Most Fun Possible on 4 wheels" is at SunBuggy in Las Vegas
It makes me sad to see all of these closed minded people when it comes to XML. They just haven't seen what XML can do and have been turned away from previous work in XML. XML can be used for data storage, and has many advantages.
XML allows data to be stored with context. For example if you have the data element "CmdrTaco", that doesn't mean much. But with xml, you can store this bit of information with context:
<SlashDot>
<Editor>
<Name>CmdrTaco</Name>
</Editor>
</Slashdot>
Isn't that more informative?
It is surprising to me that people who like OO don't like XML. OO allows you to have functionality attached to your data. XML allows you to put context (and even functionality) around your data.
Another big advantage of XML databases is the lack of a schema. If you want to have a dynamic database is the relational world, you are looking at a large schema migration. An XML database allows you to just add the information with no migration at all.
Advanced storing techniques allows query of the XML database to be just as fast as a relational database. How can that be? The XML is stored in a specialized indexed form that allows for fast retrival.
Sure, there are applications where it doesn't make sense to use an XML database. Using an XML database to store relational data doesn't make sence, that's what relational databases are for. But if you can think outside the mold, and store your data in a new way, XML databases are for you.
I might be a little biased in this area, since I work for a XML database company (http://www.neocore.com). I have seen XML in action, and it is more than just a data transport. I hope that I can convince at least one person to look at this advanced technology.
If i've just misunderstood your comment then my little animal apologies go to you.
OO databases mixed with XML == Very bad performance
This may be great for acadamia, or perhaps small projects, but in "The Real World"(tm) this won't fly. As a performance guy working on a big system, I can tell you that using OO databases and/or XML queries/storage will butcher performance.
For most of our clients, performance is the #1 concern, as that is what dictates hardware. Buying one 32-way p680 for a typical RDMS solution -vs two for a fancy OO/XML solution isn't much of a choice.
"The market alone cannot provide sufficient constraints on corporation's penchant to cause harm." -- Joel Bakan
The obvious answer is because first you have the hit of decompressing
You're thinking LZ or huffman. But you could very easily perform utilize tag-id,data-length,data.
If tag-id and data-length are binary integers, then you reduce any tag combination to 8 bytes (which, except for single character tag-names is shorter). It most definately produces faster read-times, since you read entire chunks without lexical comparisons.
For 1-level-deep data-structures, this is pretty good.. You can even reduce the tag-size down to 1 Byte (thus have only 5 bytes overhead per CDATA). This is especially good for protocols between web-server apps, and the like. For multi-levels data-structures, you have the choice of either combining all the levels into new tag-types (though this doesn't allow for recursion), or have the reader keep track of state.
Since this can easily be converted back and forth between XML, what this could mean is that externally XML is used, internally compressed XML is used.
Note that even this has limited usefulness; only at all useful when interacting with 3'rd party apps, or when being saved to disk (to allow vi-modification).
-Michael
-Michael
Separation of content, logic, and presentation is very difficult to do in current web-app developments environments.
The breakdown is not on the logic/content side of the equation, or the presentation/content side, but mainly in the presentation/logic arena.
Imagine an HTML designer who has mocked up a page for a web-app, and hands it off to the dev team for them to add in the neccessary laogic to dynamically include the user-name, current balance, contents of the shopping cart, etc. Depending on the exact paragdigm taht their tools use, they will either:
a) Chop up the page and include various fragments in the programs that are designed to emit said fragments at the opportune times to be assembled into a text stream eventually recived by a browser
or b) Various bits of logic get stuck into the page in oder to parameterize and/or conditionalize it, using either some sort of speacial tagging format or actual inlined blocks of code.
Whichever approach the dev team's tools use, the result is the same: the designer can no longer change the altered page.
Even in case b), which maintains some semblance of a coherent 'page', the designer cannot load the page-with-logic into their favorite visual editor and see anything resembling the actual page. They certainly can't edit it to change the look-and-feel without breaking the carefully constructed logic.
The end result is that the designer has no recourse other than to take their page design, change it, and hand it over to the dev-team again for them to re-include (in some cases re-code) all of their logic.
This is obviously a very wasteful approach.
Amazingly, there actually is a solution to this problem. It's called Template Attribute Language (TAL), and it solves the problem by adding programming directives to the page via XHTML attributes on the existing tags. The language is deliberately designed to only be suitable for presentation logic, relegating business logic code to some other objects, where the designer can't see them. This helps enforce the appropriate distinction between presentation logic and business logic that most current development environments ignore, thus encouraging their admixture.
Currently, TAL (and the related specifications TALES and METAL) are only implemented in one environment, but the language has been deliberately designed to be as platform agnostic as possible. Other implementations of the specification are possible, and even desireable.
Articles:
Zope Page Templates: Getting Started
Zope Page Templates: Advanced Usage
Using Zope with Amaya, Dreamweaver, and other WYSIWYG Tools
The real Webmaven is user ID 27463. I don't rate an imposter, because my ID is such a lame-ass high number.