Every database, data structure and format available today has its own comparative strengths and weaknesses. For example, one of XML's key strengths is in its schema-driven requirements structure, commonly found in government and industry standards (FHIR and HL7 for healthcare, FpML and XBRL, to name just a couple). But while markup languages don't parse as quickly as serialized JavaScript, XML performs quite well in what markup languages do: processing, definition and presentation of text.
Here are some things to consider when choosing a document storage database:
XML gets a bad reputation compared to JavaScript object notation because it doesn't parse into JavaScript as well as JSON does. However, when you consider the fact that JSON was built specifically for that purpose, it would make sense that it outperforms most things you compare it to.
When evaluating the performance factors that go into your typical .NET application, most of the work - and most of the performance - hinges on these factors:
If you look at the performance tips for DocumentDb, for example, most of the recommendations revolve the network communication alone. How much time goes in to the development and management of that factor alone in any database application, let alone DocumentDb? How much is acceptable to your application?
Network latency is one of the biggest bottlenecks in most applications today. Even if you were to use Figaro to build high-performance APIs, you still cut half of the latency out of your solution by not needing it in the back end. This speaks nothing of the other factors to consider in network communication (security being the other great concern). Figaro helps alleviate this by reducing the attack surface of your sensitive data to the application level, which not only is manageable but extremely cost-effective in the long run.
The X in XML stands for extensible, allowing people to let business decisions determine the standards of the data structure. This feature lets you define your data however you want it, and with Figaro you store it, index it, query and modify it in any way you please. Let's say you are evaluating data sources for a Content Management System (CMS) you want to build from scratch. By using Figaro as your data source, this is as trivial as storing the content data in HTML and naming it according to the blog title itself. You can replicate this functionality with XBRL, HL7 and other industry data too. Need to extract data? Use XQuery to fetch the data in the format you need it in. JSON interoperability is as simple as writing the markup the way you need it. XQuery is one of the greatest XML languages that was never truly introduced to the .NET developer community, and is still an underrated query language to this day.
There is no document format more challenging than the markup of a Microsoft Word document. And when it comes to document storage, no platform is more prepared for this data format than the Figaro .NET Document Storage database engine.
