Thursday, March 29, 2007
Friday, March 23, 2007
For SQL Server, XML Is One Answer
For SQL Server, XML Is One Answer
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:
XML has the ability to represent a single complete transaction just as well as X12 EDI, but it is more readable and more flexible. Note: I did not compare XML to a comma-delimited file (CSV). They are not in the same league. CSV can represent a single record efficiently. XML can represent records in a dozen related tables, passing all of the data needed to convey the entire business intent of a record in a consistent manner. Where CSV can represent the information on a customer, XML can represent the customer, the sales order, the line items, the payment options, and the delivery mechanisms. Since XML formats can be easily defined and expanded, it is far easier to use XML for B-to-B communication than EDI.
Parsers for XML are free, widely available, and FAST. The MSXML parser, delivered for free with Internet Explorer 6.0, will not only parse the XML and verify the data against a user-provided standard (XML Schema), but it will execute code written in XSLT. This XML based data transformation language is open, cross-platform, and very good at what it does. Finally, developers can be freed from the drudgery of writing "yet another text parser" to read and write data files.
Any system can be augmented to read and write XML. Because of it's simplicity, it is fairly inexpensive for software vendors to add XML interfaces to their applications, or to export their data in XML format. This has made XML the most universally acceptable method for transferring data from one application to another, and it has happened at amazing speed. Of course, data communication entails a great deal more than just the data format. Fields and field values, types and constraints have to be defined, just as they were before. However, XML is a common format that can be read by a wide array of integration products and translated into other formats using GUI-based tools. Applications that use XML are far easier to integrate than ever before. As we are fast approaching the end of "useful stovepipe applications," no serious architect can design systems without the ability to either publish or consume software services using XML. Conversely, any existing application that cannot play in the XML world will quickly be dismissed as hopelessly antiquated or "not serious."
So many software vendors and application architects have seen the value of XML that an entire industry has developed around providing tools for reading, parsing, translating, routing, and managing XML documents. With so many tools available, a developer faced with the need to transfer data from one application to another would be foolish to consider spending time and effort to write components that produced or consumed data in any other format. It's just not productive to write code that someone has already written and tested, which both the developer and customer already have, and which is likely to be supported into the foreseeable future.
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.
_uacct = "UA-90206-6";
urchinTracker();
Copyright © 2002-2007 Red Gate Network. All Rights Reserved.
Thursday, November 09, 2006
Thursday, July 20, 2006
logins and passwords between instances of SQL Server
How to transfer logins and passwords between instances of SQL Server
How to resolve permission issues when you move a database between servers that are running SQL Server
"Troubleshooting Orphaned Users" topic in Books Online is incomplete
How to move databases between computers that are running SQL Server
How to resolve permission issues when you move a database between servers that are running SQL Server
"Troubleshooting Orphaned Users" topic in Books Online is incomplete
How to move databases between computers that are running SQL Server
Monday, July 17, 2006
SQL Server 2000 - Log Shipping
- By the way, you can move the logins using this method:
HOW TO: Transfer Logins and Passwords Between Instances of SQL Server
http://www.support.microsoft.com/?id=246133
-To monitor the process you could use the jobs that perform the log
backups and restores. Have them email you if there is a failure. This is a
great way to email from SQL Server: XPSMTP --
http://sqldev.net/xp/xpsmtp.htm
You may find these KB articles helpful:
314515 INF: Frequently Asked Questions - SQL Server 2000 - Log Shipping
http://support.microsoft.com/?id=314515
323135 INF: Microsoft SQL Server 2000 - How to Set Up Log Shipping (White
Paper)
http://support.microsoft.com/?id=323135
325220 Support WebCast: Microsoft SQL Server 2000 Log Shipping
http://support.microsoft.com/?id=325220
821786 Support WebCast: Microsoft SQL Server 2000: Using Log Shipping
http://support.microsoft.com/?id=821786
321247 HOW TO: Configure Security for Log Shipping
http://support.microsoft.com/?id=321247
Errors
http://support.microsoft.com/?id=329133
Subscribe to:
Posts (Atom)