Perl Cd Bookshelf [Electronic resources] نسخه متنی

اینجــــا یک کتابخانه دیجیتالی است

با بیش از 100000 منبع الکترونیکی رایگان به زبان فارسی ، عربی و انگلیسی

Perl Cd Bookshelf [Electronic resources] - نسخه متنی

Mark V. Scardina, Ben ChangandJinyu Wang

| نمايش فراداده ، افزودن یک نقد و بررسی
افزودن به کتابخانه شخصی
ارسال به دوستان
جستجو در متن کتاب
بیشتر
تنظیمات قلم

فونت

اندازه قلم

+ - پیش فرض

حالت نمایش

روز نیمروز شب
جستجو در لغت نامه
بیشتر
لیست موضوعات
توضیحات
افزودن یادداشت جدید






Best Practices

Obviously, since XQuery has not been finalized, there is little user experience with it. However, we feel there is value in comparing its functionality with two alternative technologies—XSLT 2.0 and SQL/XML. Oracle Database 10g has implementations of both of these technologies.


XQuery Versus XSLT 2.0


XSLT is a mature language that has Oracle implementations in Java, C, and C++ as well as SQL access. XSLT 2.0, as discussed in Chapter 3, is incorporating more functionality, including support for data types and XPath 2.0. XQuery, which also uses XPath 2.0, is also still brewing even as this is being written, and as seen from the examples supports similar functionality. Therefore, the following are legitimate questions: Do we need both XSLT and XQuery? and Are there advantages of one over the other?

Since XSLT is a function-based language in which each template needs to be evaluated against the entire document, its processing model is considered recursive. This can produce less-than-optimum performance when processing large documents, not only because XSLT processors require an in-memory representation of the entire document, such as DOM, to traverse, but also because the frequent XPath traversals reduce throughput of the processing.

XQuery, on the other hand, while still using XPath, is neither function-based nor recursive. Therefore, its processing model can be optimized by compiling the queries, potentially producing more efficient processing. However, XQuery, without XQueryX, is not an XML syntax, thus limiting its integration into an XML processing stack.

Finally, between the work being done to compile XSLT stylesheets and the fact that few XQuery implementations exist due to the standard’s draft status, the verdict is still out as to whether both will find a niche or one will prevail.


XQuery Versus SQL/XML


In the case of XQuery versus SQL/XML, they are two emerging standards that can be considered to be competing for the same function space. We will be discussing SQL/XML in detail in later chapters because its functionality is included in Oracle Database 10g. Of particular note is that SQL/XML depends on SQL for its datatype support and not XML Schema. Thus, as its name implies, SQL/XML integrates XML processing with SQL and therefore would be the technology of choice for SQL environments or when you need to mix table-based, structured data with XML or document data.

On the other hand, XQuery is designed for an XML environment where a database is not a required component. While it will access collections of documents, it does not depend on any particular repository model. It is also designed to work with XML Schema data types. Therefore, taking into account the XSLT issues, XQuery will generally be the choice where your XML processing doesn’t have access to or will not benefit from a SQL engine and requires XML Schema support.

/ 218