I’m Thankful for You
SSWUG is an USA based company with a worldwide audience. Recently I celebrated the USA tradition of a thanksgiving holiday. Many cultures have a similar tradition; in my home we use this time to be thankful for the many blessings we have received the previous year. This year, I wish to thank you for being gracious readers.
The SSWUG site as well as the newsletter is unique in format, providing you a consistent voice for lessons learned, opinions or questions. I have a tendency to write the daily newsletter entries with an intentional bent based on my personal knowledge, experience or understanding. I do my best to provide solid direction, or raise relevant questions, yet still find I sometimes don’t quite hit the mark.
These times are when I am most grateful to you, our readers. Frequently, I receive notes of encouragement and thanks. More useful to me, however, are the notes of correction or concern. When someone responds with professional respect, having a different point of view, we all benefit. It is for this reason I post nearly all replies, even if I am personally 100% opposed to the position.
It is this give and take from those who take the time to send their knowledge that make the SSWUG newsletter much bigger than I could ever take it myself. So, this year, for 2012, I am most thankful for the opportunity to write daily for SSWUG, and for those of you who take the time to read, critique, and respond.
Tomorrow, we are picking up where I left off Friday regarding the storage of XML in your database. Let me start off by saying I have not personally experienced a need to store much XML in any database. Obviously my experience is going to be limited to my 30 years of database programming in many industries. So I don’t pretend to know that there is never a need to store XML, on a large scale, in your database. My reasoning is as follows, based on two principles…
- If the XML contains data that may be useful, and is valuable stored as XML, SQL Server performs best if the XML is accompanied by an XSD. If you are able to produce an XSD for the data, then the data is well enough known to be stored in SQL Server tables. This form of XML is simply not taking the time to generate native storage, which may be fine in the short term…but makes no sense in a long term production database.
- If the XML does not contain useful data, and is simply a Binary Large Object similar to a word document where the existence of the document is the data, not any individual contents within the document, there are better techniques for storage than importing the data into your database schema. SQL Server is not a good/efficient file server mechanism. We covered many of the different techniques for this problem a few weeks back.
That will be the foundation for my position in the newsletter tomorrow. If you would like to join in with the discussion, please send your comments to btaylor@sswug.org.
Cheers,
Ben
$$SWYNK$$
Featured Article(s)
XML Support and SQL Server (Part 1)
Beginning with SQL Server 2005, Microsoft improved and expanded its eXtended Markup Language (XML) support, the activities that previously required complementary products now have native support. Native XML commands and utilities have been expanded to include new features. In this article, I’ll give you an overview of XML.
Featured White Paper(s)
Encryption & Key Management for Microsoft SQL Server 2008/2012
Simplify encryption and key management on your SQL Server. Data thieves are targeting SMB companies because of their inadequa… (read more)