After analyzing the above results, we conclude that the native XML database has better performance than the XML-enabled database for handling XML documents with larger data sizes. Although the XML-enabled database has better performance for small document sizes (number of records <= 1,000), it cannot handle large-sized documents as efficiently due to conversion overhead. In contrast, the native XML database engine directly accesses XML data without conversion.
Although the native XML database provides high performance in handling XML documents, it does have some disadvantages. From calibrating the database size, both data and index size consumed by the native XML database is much larger than in the XML-enabled database.
Both databases have steady performance in single data operations: insert, delete, and update. From 100 records to 50,000 records, the result is more or less the same. The native XML database has better performance in searching by index.
For mass record operations, the native XML database shows advantages in handling large quantities of XML data. Both the results of bulk loading and delete operations are very similar to the results in reconstruction. The XML-enabled database has better performance in small database sizes. The native XML database provides better scalability as the database grows. For mass updates, the native XML database still has advantages, but the difference is not so obvious as in the previous case. As the XML-enabled database needs one SQL statement to perform mass updates, the native XML database achieves this indirectly. We have tried to discover any API of the native XML database that provides mass update functionality but without success. It seems that update functionality is a weakness for this native XML database. Instead, we have to retrieve a single document, change it by another API, and then return the results to the database or display them through XSL. This consumes quite a lot of running time.
The native XML database produced better results in the reporting section, which implies that the native XML database X-Query has performance gains from query optimization. Most of the figures show that the XML-enabled database starts better but becomes worse as data size grows. The difference becomes obvious as the query becomes more complicated. Q17 and Q18 in Figures 20.12 and 20.13 demonstrate this.
Both products have advantages and disadvantages in developing applications. In using the native XML database APIs, the compatibility is high for applications written in Java. Since the XML-enabled database is a proprietary product, the application can run only in certain operating system environments. When compared to the XML-enabled database, Java is a relatively low-level language. More coding is required, and hence the debugging time and also the maintenance cost are increased if the application becomes complicated. Since the native XML database is a new product, the technology related to this product is not well known to most developers. It takes time for most IT developers to get accustomed to this new product.
Both the XML-enabled database and the native XML database provide good graphical user interfaces. The native XML database uses a Web-based application, which acts as the centralized database administration software, while the XML-enabled database is a Windows-based application. In order to communicate with the database, both the XML-enabled database and the native XML database use the same approach by sending HTTP requests that use a URL syntax. The XML-enabled database needs the annotated schema as a middle tier to map the XML objects into the corresponding database object. The XML-enabled database is developed so that programmers do not have to learn from scratch. However, since the native XML database is a new product, programmers need time to learn new concepts and functions before using it.