Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Usenet -> c.d.o.server -> Re: Development Trends in Web and Oracle

Re: Development Trends in Web and Oracle

From: Hexathioorthooxalate <ruler_at_removemetoemail.clara.co.uk>
Date: Sat, 12 Mar 2005 17:24:59 -0000
Message-ID: <1110648292.35444.0@iris.uk.clara.net>

"Noons" <wizofoz2k_at_yahoo.com.au> wrote in message news:4232fddd$0$5462$5a62ac22_at_per-qv1-newsreader-01.iinet.net.au...

> You see, this is where your whole argument falls down. If ALL you want
> to do with data is "persist" it, then WTF are you doing using
> a database in the first place? Store it in a file and be done with it.

If the XML is data, where do you store data. I store data in a database, I don't know about you. It appears to me you do not like XML because of the sole reason that it is verbose. And because it is verbose, through some wierd logic you shouldn't store it in a database. Of course you should! I still don't know why you shouldn't.

> And a lot of overhead. And it is arbitrary. And it is subject to
> multiple interpretations. And makes no sense whatsoever to
> retrieve the data in a consistent, reliable and usable fashion,
> which is the fundamental reason to use a db instead of a flat file
> in the first place. In sum: it adds NOTHING to the process,
> except overhead. We've got enough of that, thanks.

Crikey. I want my data in a consistent reliable usable fashion, using a relational database is not the only way of doing this. XML can offer this, and in bucket loads with far more data integrity. It's the whole point; data exchange, integrity, and standards enforcement. And further, data integrity isn't **overhead**!

Further, the same XML schema the database uses to validate the XML can be used by the middleware or front-end. In a solely relational database, the only way you have of ensuring the data is valid etc and obeys business rules implemented within the database is to attempt a database operation such as an insert. Using the same XML schema that the database uses to validate the XML, I can validate beforehand, before contact with the database. That's reducing the overhead isn't it ;)

>> Overhead of 36*2+1 longer ... Huh?? This calculation doesn't hold water.
>> I elaborate.
>
> It is an exageration. To illustrate the ridiculousness of using XML
> in a database.

The XML isn't stored with this verboseness. It is shredded upon insert and recomposed upon query. Further it isn't rediculous.

Incidently, verboseness isn't a problem nowadays anyway. We don't have to skimp on bytes here and there because storage arrays or memory are expensive. When Y2K happened, I for one wasn't screaming about losing another 2 bytes because we had to store dates as 4 digits and not 2 :)

>> With XML data stored in the database, the information being inserted can
>> be checked for bounds, its content etc significantly more comprehensively
>> than using the traditional relational approach (eg. XML schema on an
>> XMLTYPE table column).
>
> Prove it. Don't just state it.

When I did my XML 101 course years ago .... for goodness sake Google it out or read the Oracle docs yourself. But here is a brief XML Schema and discussion to put the comments in context for this posting.. I have defined a company below. It defines the root note "whateverRoot" containing many companys where each company has a name, address, and registrationdate.

<?xml version="1.0"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">  <xs:element name="whateverRoot">
  <xs:complexType>
   <xs:sequence maxOccurs="unbounded">
    <xs:element name="Company">

     <xs:complexType>
      <xs:sequence>
       <xs:element name="CompanyName">
        <xs:simpleType>
         <xs:restriction base="xs:string">
          <xs:length value="50"/>
          <xs:minLength value="5"/>
        </xs:restriction>
        </xs:simpleType>
       </xs:element>
      <xs:element name="Address" type="xs:string" minOccurs="1" 
maxOccurs="5"/>
      <xs:element name="CompanyRegistrationDate" type="xs:date"/>
     </xs:sequence>

    </xs:complexType>
   </xs:element>
  </xs:sequence>
 </xs:complexType>
 </xs:element>
</xs:schema>

Here, when the XML inserted into the database is validated against this schema, it ensures that the XML being inserted conforms to the structure, that the company name is between 5 and 50 chars, and that between 1 and 5 lines of address can exist, and that the CompanyRegistrationDate is present in the format CCYY-MM-DD. Even this simple example, it can be seen that there is significant data validation (the company name must have between 5 and 50 chars, and there must be at least 1 and at most 5 lines of address, the company name and registration date exist and are not null). It could be so much more complex such as validating company VAT numbers with regex's etc, performing boolean logic on various element values ensuring at least one of something is present etc. Doing something like this not using XML would require check contraints, stored procedures, etc to give the same level of confidence in the data. Quite a bit of PL/SQL programming. Further, when I retrieve information out of the database, I know the data structure, I know the date is in the format CCYY-MM-DD and not some locale setting or American format (because the date structure is defined by XML standards @ W3C). I could even define my own format (not that I would) for the date too, and the format would be defined in the XML schema. Truely portable & open.

> And a lot of overhead. And it is arbitrary. And it is subject to
> multiple interpretations. And makes no sense whatsoever to

To validate data against this schema has overhead, as does validating data in stored procedures, check constraints etc. It isn't a matter of putting together some metrics to sway the argument one way or another and prove anything. The overhead depends on the extent of data validation etc required in each approach.

Something not addressed in the thread so far is ease of maintenance of the data model. In a purely relational model, if you wanted to modify the database schema to contain 6 lines of address, it might require a considerable amoutn of work if the table were constructed "CREATE TABLE company(companyname VARCHAR2, addressline1 VARCHAR2 .... addressLine5 VARCHAR2). Here you would have to alter the underlying base table to include addressLine6, change all dependent views to return the 6th line of address, change all middleware to know about the additional line of address, front end apps etc it goes on. With XML all I would do is change, in the XML schema example above, maxOccurs="5" to maxOccurs="6" - or even maxOccurs="unbounded" if you didn't want to impose a limit. It is more or less done. The dependent apps already understand XML & should know how to process it. And, in this example, it could be done with no database down-time!

> If all you see in a database is "persistence", then you missed 35 years
> of IT evolution and the fundamental reason for storing data in databases
> instead of flat files. And I don't have the time to explain to you

I don't think you understand what XML is all about and have missed much yourself. This is not a fad and there is a requirement to store XML in a database. What I need to know is, as suggested a few postings back in this thread, why this should not be done and what are (valid) reasons. I don't believe I have any yet.

> And a lot of overhead. And it is arbitrary. And it is subject to
> multiple interpretations. And makes no sense whatsoever to
> retrieve the data in a consistent, reliable and usable fashion,

"Prove it, don't just state it" is pretty cheap to say so I don't expect you to backup this comment because I can use Google. But in my contrived example above, what overhead is there in a relational database to ensure that a company name must be at least 5 chars and no more than 50 chars, to do ..... and there is so much more than I have included in this little schema validating information. This brings up another argument about data integrity. I would have much more confidence in XMLschema valid data like this,

Something I think you don't appreciate too is that if a web tier is talking XML or HTML (through XSLT and/or CSS), if the middleware is talking XML, then how can it be defensible to retain an impedence mismatch in the database. I come back the same question again, why not store XML in a database?

> Metadata verbosity IS the fundamental reason!
> Why the heck do I need the metadata REPEATED for
> every instance of the data? What possible purpose
> could that serve?

Didn't understand this. The highlight of REPEATED is meant to imply what - what the data isn't normalised or something?

> relational does it much more efficiently and is a reliable way of
> RETRIEVING the data back in many forms.

Bollocks it does. Read up on XSLT. Amongst other things with XSLT you can convert one rendition of XML into XML of another grammar and syntax; convert XML into HTML, convert XML into PDF's (using XSLT-FO), convert XML into CSV, convert XML into plain text or flat file. And even if you wanted to expose XML stored in your Oracle database as though it were relational (for example is there was staged development of an XMLDB), you can use XMLTYPE VIEWS.

By the way, the thread title is "Development Trends in Web and Oracle". XML is a trend, a big one, despite us disagreeing.

Regards
Hex Received on Sat Mar 12 2005 - 11:24:59 CST

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US