Implementation

SQLDOM was created for Microsoft SQL Server (version 2005 or later).

It does not make use of CLR. It is written entirely in T-SQL.

SQLDOM is implemented entirly with temporary objects. No permanent SQL objects or modifications to user databases are required. (i.e. SQLDOM is set up to run entirely within tempdb.) If desired, users could modify or incorporate SQLDOM into other databases, but there are good reasons to let SQLDOM exist in tempdb.

Performance is good, though not as fast as a parser written in C++. For example, parsing the Google home page HTML takes roughly 150ms on modest hardware. Rendering HTML is slightly faster--roughly 120ms to render the HTML of the Google home page from the DOM.

When considering performance, remember that while an external parser may be somewhat faster at the raw work of parsing and rendering HTML, real-world implementations of other solutions (ASP.NET, PHP) introduce other performance-limiting factors and introduce additional complexity. In other words, it is possible that performance of a SQLDOM-based solution will outperform other solutions because of performance gains from the streamlining of the architecture.

SQLDOM implements 4 tables to store the DOM:

#tblDOM

Has a row for each node (HTML tag). Text nodes are stored in their own row (because they are technically a separate node).

#tblDOMAttribs

Has a row for each attribute name/value pair of a node

#tblDOMStyles

Has a row for each CSS style of a node. These are concatenated together to make up the style attribute of the node.

#tblDOMDocs

If multiple HTML documents are needed simutaneously, each document has a row in this table to allow DOM elements from multiple documents to be stored in #tblDOM