Has anyone created a custom engine that includes the MS (or other) XML
provider and instituted XQuery functionality similar to SQL 2005?

I'm not interested in schema enforced XML, or XML indexes, just the querying
functions on an untyped XML (or memo or string) column.

Any thoughts of adding this to the new DB?

Thanks

Jerry,

<< Any thoughts of adding this to the new DB? >>

Not initially, no.  Frankly, I'm not entirely sold on using XML as the basis
for any type of database engine functionality.

--
Tim Young
Elevate Software
www.elevatesoft.com

Tim

>I'm not entirely sold on using XML as the basis
>for any type of database engine functionality.

If you wanted totally variable fields, the ability to have fields or not in a record I can see a use for it, but otherwise, even though I know cpu's and disks are getting faster I don't see the benefit of having to scan a text file for <record><field 1> markers as being a good use of computer time. Yet another way of soaking up the extra performance in the hardware with slower software.

Or am I misunderstanding what an XML database would look like?

Roy Lambert

Roy,

<<Or am I misunderstanding what an XML database would look like?>>

I don't think so... Recently I looked at a Music XML file, and it was so much text
to produce so little sound.

Dan

> If you wanted totally variable fields, the ability to have fields or not
> in a record I can see a use for it, but otherwise, even though I know
> cpu's and disks are getting faster I don't see the benefit of having to
> scan a text file for <record><field 1> markers as being a good use of
> computer time. Yet another way of soaking up the extra performance in the
> hardware with slower software.

Roy,

I have a system where the my client's data structures are *extremely*
dynamic;  each time they do work for one of their client's, there's new
specialty categories that need tracked.

So, I have the data in an XML, and I export the common search items (about 5
or 6 items) to field level.  Term for this is "property promotion".

The searches aren't bad at all, because well over 95% of all search criteria
is included in the 5 or 6 promoted fields, and then I only have to shred the
xml for the remaining.

I also store text documents in XHTML instead of RTF and use the XML services
to query for words in specific sections.

Works very well in this scenario, but certainly not a design that's right
for all situations.

Jerry


I'm being nosey

>I have a system where the my client's data structures are *extremely*
>dynamic; each time they do work for one of their client's, there's new
>specialty categories that need tracked.

What?

>So, I have the data in an XML, and I export the common search items (about 5
>or 6 items) to field level. Term for this is "property promotion".

Lost me there

>The searches aren't bad at all, because well over 95% of all search criteria
>is included in the 5 or 6 promoted fields, and then I only have to shred the
>xml for the remaining.
>
>I also store text documents in XHTML instead of RTF and use the XML services
>to query for words in specific sections.

Duh?

>Works very well in this scenario, but certainly not a design that's right
>for all situations.

That bit I understand <vbg>

Roy Lambert

> I'm being nosey
no problem

>>I have a system where the my client's data structures are *extremely*
>>dynamic; each time they do work for one of their client's, there's new
>>specialty categories that need tracked.
> What?
My clients do work for hospital systems.  Each of their contracts with a
hospital may involve capturing different patient information based on the
type of work involved--radiology for this hospital, which is *completely*
different from pathology at that hospital which is *completely* different
than workman's comp at that other hospital.

>>So, I have the data in an XML, and I export the common search items (about
>>5
>>or 6 items) to field level. Term for this is "property promotion".
> Lost me there
Well, there's an xml structure that's extensible for storing the disparate
data items, but there's a few common search fields: Last Name, First Name,
Patient ID, Visit ID, Admission Date, that are common across each of the
specialties.  These search fields are put in regular database fields (speed
of query), after being updated from the xml.

You might ask "why not put them in regular fields in the first place?"
Well, the clients may want to extend the search fields and now it's just a
new mapping from the xml to a field.  Plus, that keeps the xml as the sole
trigger point for data access and the other fields as just search items.

>>The searches aren't bad at all, because well over 95% of all search
>>criteria
>>is included in the 5 or 6 promoted fields, and then I only have to shred
>>the
>>xml for the remaining.
>>
>>I also store text documents in XHTML instead of RTF and use the XML
>>services
>>to query for words in specific sections.
> Duh?
I have text documents, that I store in XHTML format, (an xml-enforced
version of html), instead of RTF format.  Since XHTML *is* xml, I can use
the same xml based query engines to grab data out of the middle of a
document as querying the non-promoted fields in the DB.

HTH,

Jerry

Jerry


It helps in reducing the size of my nose

Interesting, and as always "I wouldn't have done it that way" but it looks pretty sensible

Roy Lambert

Tim Young [Elevate Software] wrote:

>
> Not initially, no.  Frankly, I'm not entirely sold on using XML as the basis
> for any type of database engine functionality.
>

Me either. Maybe for storing configuration information, although I
prefer .ini files for that purpose. But for a dataset that contains
100,000 rows, no way.

I'm developing some software that stores image data in blobs. With
approximately 750 rows, one table is over 400KB and its corresponding
..blb file is over 400MB. Thank God I don't have to do all of this in XML!

Mark

> I'm developing some software that stores image data in blobs. With
> approximately 750 rows, one table is over 400KB and its corresponding .blb
> file is over 400MB. Thank God I don't have to do all of this in XML!

Funny, I store voice files but would never keep them in the database, (keep
them linked by ids and file locations)

But seriously, the XML I keep with SQL 2005 are smaller structure files,
maybe about 20-30 nodes.  It's just that if I didn't keep it dynamic there,
I'd end up with (no kidding), hundreds of different data tables, just for
keeping dynamic info.

If my XML structures were large and my data was mildy variable, wouldn't do
it that way.  But, am *shocked* by how well it works in Sql 2005; very fast,
very searchable for the off times where it's need to be searched upon.

One of those different strokes things