At 9:14 AM +0100 8/21/01, Rich Wild wrote:
>yes, yes you can. Its fun as well!
>
>An example of where we've used this is to queue emails that an admiistrator
>wants to send until such time as he wants to send them.
>
>To normalise this would be a real pain as there are so many factors
>involved, so we didn't.
This is one of the major drawbacks of using an RDBMS to store
(essentially) XML documents... normalization is a bear, so you don't
do it... but then the XML is just o single, large entity. You can't
really do anything with it using the db engine, except store/retrieve
it and parse it into something meaningful with a program, In your
"queuing email" example, it would be difficult (if not impossible) to
query the XML field and extract several emails based on some
criteria... or worse yet update a single email.
There is a new class of databases evolving to address this... where
the XML is stored in an hierarchical fashion which represents the
structure of the XML documents (or hashes/CF structures, for that
matter). The elements of the XML document do not lose their identity
and can be manipulated and queried by the db engine.
While an XML database is not a replacement for an RDBMS (nor is it
meant to be), there are some significant advantages to certain
applications... especially when exchanging XML data with other
applications/sites/programs.
A couple of advantages are:
the data and structure are easily read and understood by humans.
related data are contiguous, rather than dispersed among many tables, e.g.
you can easily reach in and grab an order from a document containing many
orders
The data structure is ad hoc and a more natural representation of the
needs of the application
One example application where an XML database would be superior to
RDBMS is an online ordering system (essentially a shopping cart)
where multiple orders of several hundreds of items are created,
massaged, then forwarded via XML to another destination....
I have a client with such an application. His distributors place
large restocking orders with him. These are minimally processed,
then forwarded to the manufacturer for billing/shipment, etc.
Memory-based structures would be OK... they are ad hoc and easy to
manipulate. The problems are: they would be very large; and would be lost if
the server crashed. Who wants to reenter several hundred items.
A RDBMS-based cart is OK... I have used them... but they don't really fit
the needs of a work file... first you split the information apart
so the db is normalized... then you need to gather it together to process
id... a lot of extra programming for a temporary "work" file.
An XML-db-based cart would be be the best of both worlds.
I don't know of any XML db implementations which are accessible to CF
programs ...yet.
However the people at torchbox have an "in-memory" approximation of
an XML db engine that you can use to gain experience with
manipulation of XML. See the:
CF XML Toolkit
at:
http://torchbox.com/xml/toolkit.cfm
Results of some limited experiments with this for the above client:
Memory-based XML, is somewhat slower than memory-based structures. This is
expected because of the overhead of the XML parser.
But, parsing would be done within the (future) XML db engine (along with
caching, etc). It would probably place less of a burden on the CF program
and db engine than a comparable RDBMS-based solution.
The results are promising... you get the ease of structures and the powerful
equivalent of SQL query manipulation an an acceptable performance.
In addition, the document is already an XML document, its ultimate format (as
far as we're concerned). This means we can just cfhttp post it to the
manufacturer's site.
HTH
Dick
> We just kept the queries stored in a text column as
>wddx and then pulled them out and deserialised them as required. The 'just
>add water' approach. Probably breaks all sorts or arbitrary guidelines for
>data handling but it works like a charm...
>
>> -----Original Message-----
>> From: Aidan Whitehall [mailto:[EMAIL PROTECTED]]
>> Sent: 21 August 2001 09:27
>> To: CF-Talk
>> Subject: Storing complex data types
>>
>>
>> Can you use WDDX to store a complex data type (such as a
>> session variable
>> which is a structure of structures) in a string format that
>> you can dump
>> into a database field and then pull back out the next time
>> that user logs
>> in?
>>
>> If not, is there any other way of doing it? I want to avoid having to
>> normalise the data and produce a mini-schema for user settings.
>>
>>
>>
>> Thanks
>>
>> Aidan
>> --
>> Aidan Whitehall <[EMAIL PROTECTED]>
>> Macromedia ColdFusion Developer
>> Fairbanks Environmental +44 (0)1695 51775
>>
>
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Structure your ColdFusion code with Fusebox. Get the official book at
http://www.fusionauthority.com/bkinfo.cfm
FAQ: http://www.thenetprofits.co.uk/coldfusion/faq
Archives: http://www.mail-archive.com/[email protected]/
Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists
