Login ProductsSalesSupportDownloadsAbout |
Home » Technical Support » DBISAM Technical Support » Support Forums » DBISAM General Discussion » View Thread |
Messages 1 to 10 of 17 total |
XML query |
Sat, Sep 23 2006 1:40 PM | Permanent Link |
"Jerry Hayes" | 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 |
Mon, Sep 25 2006 2:18 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | 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 |
Tue, Sep 26 2006 2:59 AM | Permanent Link |
Roy Lambert NLH Associates Team Elevate | 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 |
Tue, Sep 26 2006 8:54 AM | Permanent Link |
Dan Rootham | 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 |
Tue, Sep 26 2006 9:01 AM | Permanent Link |
"Jerry Hayes" | > 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. |
Tue, Sep 26 2006 11:44 AM | Permanent Link |
Roy Lambert NLH Associates Team Elevate | 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 |
Tue, Sep 26 2006 1:42 PM | Permanent Link |
"Jerry Hayes" | > 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 |
Wed, Sep 27 2006 4:38 AM | Permanent Link |
Roy Lambert NLH Associates Team Elevate | 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 |
Thu, Sep 28 2006 8:02 PM | Permanent Link |
"Mark A. Andrews" | 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 |
Thu, Sep 28 2006 8:21 PM | Permanent Link |
"Jerry Hayes" | > 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 |
Page 1 of 2 | Next Page » | |
Jump to Page: 1 2 |
This web page was last updated on Friday, September 20, 2024 at 05:39 PM | Privacy PolicySite Map © 2024 Elevate Software, Inc. All Rights Reserved Questions or comments ? E-mail us at info@elevatesoft.com |