A New Query Language
-
Did you know there's a new query languange you should be learning? Today we have an Introduction to XQuery from Michael Coles, which should help you get started. If you're looking for more information, there's actually xquery.com and a tutorial from W3Schools.
Personally I've let me XML skills dwindle, having started learning to process trees 7 or 8 years ago and then not doing a whole lot with XML since. Since this is XML week, however, I'm getting a little inspired to do some work here.
And you should too. I can bet that you'll start seeing more and more XML documents stored in your SQL Server databases. Either in the new native XML datatype, or as strings in SQL Server 2000 databases, but developers like working with XML and I bet they'll be slipping new documents in under your noses. That's if they haven't already.
Years ago I saw MDX as an up and coming language, but after writing a few queries in the early part of this millineum, I found it to be very complicated and confusing and without a definite project to work on, something I didn't pursue. My bet was that most companies wouldn't be using it heavily and I think I've been right about that one to date. The whole BI/Analysis Services/cube structure thing has yet to become very prevalent. It's out there and if you can work with it, you can get very well paid, but it's not common.
That's changing, albeit slowly, but I bet XML documents in the database and XQuery overtake it rapidly. Developers writing .NET applications have probably spent a good amount of time with XML and I would venture to guess that we'll see more and more SQL Server applications, especially those using the SQLCLR, with XML data inside.
So check out Michael's article and start growing your career a bit more today.
-
How many billions have Microsoft, Oracle and others spent on developing optimised relational database systems? Why throw it all away in favour of a heavily padded flat file format? It is just about justifiable to use xml as a standard protocol for communication between disparate applications (although I would argue that point too) but, for data storage, its (literally) a waste of space. Anything that allows me to efficiently turn xml into a sensible relational structure has my vote! (By the way, I'm a developer, not a DBA).
-
First, I agree with Stewart that XML is a huge waste of space... That said, I like it a lot in .Net development. When someone uses an XML file to store some settings I can easily see the gist of what these settings mean. Can you say, "Self Documenting" children.
I can't tell you how many times I've studied column names in an otherwise fine database and was mystified about the data being stored there.
As I see it, XML and databases are two different tools. XML will never replace a well designed database, but it has many uses where the database is overkill.
If the world had put me in charge would I have come up with XML as a solution. Maybe not, but form does follow function here:-)
-
Three years ago, the powers that be decided that we needed to use XML. So, now we support a database filled with XML documents that could have been much more efficiently stored in relational tables. I struggle with seeing the advantages of using XML.
Scott
-
XML doesn't make sense in most databases. There are places where it does, but for the most part it is a waste. However using it as a parameter is a nice thing and learning to query it could help you decompose it or extract what you need.
The one place it seemed to make sense in a DB that I can think of now is for state info. The old Microsoft.com (or msn.com?) (4-5 years ago) used it to store state info for users that weren't logged in. They built an xml document of state info that they stored in a temp field. If you logged in, they decomposed it quickly and went with their normal relational store of who you were, preferences, etc. If you disconnected, they cleaned it up after a few days.
Viewing 5 posts - 1 through 4 (of 4 total)
You must be logged in to reply to this topic. Login to reply