Subject | Re: [Firebird-devel] XML support in database |
---|---|
Author | Paul Schmidt |
Post date | 2003-04-05T22:20:47Z |
On April 5, 2003 06:29 am, Nickolay Samofatov wrote:
had to be Java, heck Oracle even added the ability to write SPs in Java,
now it's just another programming language, useful in some places, less
useful in others and useless in still others.
It's like operating systems, we need to decide what needs to run in kernal
space (or db engine space) and what needs to run in application space.
For example can we store XML as a blob, suck it out of the database, run it
through a parser in the application, add in any other data that is needed
using standard SQL, and the format it to output?
In other words can this be accomplished outside of engine space? I think it
can, so it belongs in application space. Now we may be able to make this
easier, by adding another blob subtype for XML as a hint to the application
that this is an XML document your using. Some features would be nice anyway,
like the full text search, but we have to be careful that we don't add a lot
of baggage to the engine. Firebird currently has a nice balance between
engine size and feature count, lets not upset that balance.
> Hello, All !<snip>
>
> I analysed the need for XML support inside of database. Here are the
> results.
> There are four common business uses for DMBS now (this is from my
> experience).
> III. Content store system (Web Portal module of common ERP applications)I think that XML is todays next-big-thing<tm>, a few years ago, everything
> This class of systems appeared quite recently. In general, content for this
> systems
> is prepared in different DSS and OLTP modules and stored in XML format
> inside of the
> content store database. Corporate/govermental Web portals access this
> content database
> and present it to the user. XML documents stored inside the database are
> converted
> to XHTML using web server facilities (such as JSP). Documents are more or
> less static
> inside of the database, but often need arises to extract some specific data
> from them
> or convert them to different format. This task can be eased if database
> supports
> XML natively. Firebird lacks some features useful for this class of
> systems: 1. full-text search!
> 2. native XML datatype
> 3. XQuery support in SQL
> 4. XML transformations support in queries (for example, using XSL)
> 5. DOM support in stored procedures
had to be Java, heck Oracle even added the ability to write SPs in Java,
now it's just another programming language, useful in some places, less
useful in others and useless in still others.
It's like operating systems, we need to decide what needs to run in kernal
space (or db engine space) and what needs to run in application space.
For example can we store XML as a blob, suck it out of the database, run it
through a parser in the application, add in any other data that is needed
using standard SQL, and the format it to output?
In other words can this be accomplished outside of engine space? I think it
can, so it belongs in application space. Now we may be able to make this
easier, by adding another blob subtype for XML as a hint to the application
that this is an XML document your using. Some features would be nice anyway,
like the full text search, but we have to be careful that we don't add a lot
of baggage to the engine. Firebird currently has a nice balance between
engine size and feature count, lets not upset that balance.