Thank this author by sharing:
By Nick Malik,
Many folks describe XML as a method of separating the presentation of data
from the management of the data. It is true that XML started there.
However, XML is not a presentation format. It is a data communication
format. The idea of separating data presentation from data management goes
to a basic Object-Oriented application design, commonly called
Model-View-Controller. For this design to scale, there has to be a way for
the model (which manages the data) to statelessly communicate with the view
(which presents it). XML was developed to be that format.
To make it work, XML had to be stateless, scalable, and yet easy to describe
and understand. Therein lies its advantage. That advantage can be
applied to other problems as well, some with more effects than others.
So what makes XML so useful:
Certainly, XML is not good for all uses. Just as I'd be less than
enthusiastic about SQL Stored Procedures filled with thousands of lines of
procedural code, XML can be used in ways that are not efficient or even
sensible. However, to point to a misuse of a technology and then criticize
that technology because it failed to do well, is hardly a useful conversation.
OK, so XML has its place. But what about inside SQL Server? Why
did Microsoft add XML capabilities to their flagship RDBMS system? It was
the right thing to do.
While the value of SQL Server comes from it's exceptional qualities as a
relational data system, companies need their programmers to be productive.
It costs a huge amount of money to develop software, whether for new
applications or for system integration. By providing XML interfaces in SQL
Server, and providing XML tools and libraries to programmers, Microsoft has set
the stage for a level of developer productivity that could not have been
imagined just a few years ago.
Using XML based interfaces, software developers can avoid having to write
lengthy and buggy "database layer" code, choosing instead to write code that
simply loads and unloads data from objects to XML using built-in tools.
Less code to write = less code to test, debug, and deploy = faster delivery of
better code. That's a hard equation to beat. Additionally, adding
XML capabilities to SQL Server doesn't detract from the strengths of the
product. It's just as fast, scalable, and reliable as before.
Should SQL Developers become XML experts? That depends. Clearly,
there are times when XML is very useful and cost efficient. Programmers
and business users depend on data professionals to manage their data storage and
retrieval systems, and to be familiar with best practices in data architecture,
integration, and openness. I'd hate to be the SQL developer who
recommended against XML because I failed to see how much money the business can
save by using it.
Writing corporate development standards
As a data guy, I always smile when application developers refer to ‘their’ data. If only it were tha...
There are lots of systems for developing software, but it often seems that DBAs don't adhere to any ...
Part four of this series on rapid application development looks at the CRUD routines that are needed...