NYCPHP Meetup

[Kenneth Downs]

csnyder wrote:
> On 8/8/07, Elliotte Harold <elharo at metalab.unc.edu> wrote:
>
>   
>> Some relational databases have added non-relational, fulltext search
>> extensions to their products just as some have added non-relational XML
>> extensions. These are adequate for simple uses, if you don't push them
>> too hard. However they are completely incapable of carrying out queries
>> like, "Give me the title and first paragraph of every chapter of this
>> book" (something Safari routinely does) because they don't see the
>> structure of a document, only the text.
>>     
>
>   

Select title
          ,SUBSTRING(text ...insert regexp here...)
  from chapters
 where book_name = 'XML in a Nutshell'

Rusty, you appear to be arguing from ignorance, very unusual coming from 
you.

The true difference between us in this argument is that I understand 
that I have a prejudice for relational over hierarchical, based on my 
knowledge and use of both, and based on judgment calls as to how to get 
through the day.  I daresay however that you are promoting a religious 
favoring of XML w/o a working knowledge of the alternatives.

You simply cannot defend a file format as a foundation for frameworks 
and databases.  The best you can do is defend the model, such as the 
hierarchical model.

Going further, you cannot defend a file format as a foundation for 
anything based on how it handles large text (or binary) fields.  There 
are three issues here:

-> Data model, hierarchical vs. relational. 
-> File format, XML vs YAML or JSON or any other format you like
-> Handling of large text (and binary) columns.

Finally, if we can all admit that XML is just a file format, then the 
entire framework crumbles as soon as somebody comes up with a better 
one, because let's admit it, XML is just about the worst you're going to 
find.

In conclusion, the examples you provide appear to give advantage to XML 
because tools exist to handle data that has been buried in opaque 
formats and poorly defined structures.  If the data had been structured 
properly in the first place and put into formats that were not so 
opaque, using (pardon me for saying) a *real* database, designed on 
solid principles, the examples you give become child's play.



> I'm glad we have multiple tools to bring to bear on this kind of
> problem, because I worry about the performance implications of
> querying an XML database for the average price of those books, or
> performing an operation that adds another field (tag?) to each book's
> "record".
>
> If it's not too much trouble, could you give us some other use cases
> for an XML database? Because title and first paragraph, if that's
> something a system "routinely does" could easily be stored as
> relational data at the time of import.
>
>   


-- 
Kenneth Downs
Secure Data Software, Inc.
www.secdat.com    www.andromeda-project.org
631-689-7200   Fax: 631-689-0527
cell: 631-379-0010

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.nyphp.org/pipermail/talk/attachments/20070809/436e8d0c/attachment.html>