[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: xml schema best practices question.. one big xml orlots of

  • To: Michael Kay <mike@s...>
  • Subject: Re: xml schema best practices question.. one big xml orlots of little components?
  • From: Leevi Graham <leevi@t...>
  • Date: Sat, 16 Apr 2005 19:51:45 +1000
  • Cc: xml-dev@l...
  • In-reply-to: <200504160857.j3G8v1w0014934@e...>
  • Organization: The Leviathan Project
  • References: <200504160857.j3G8v1w0014934@e...>
  • Reply-to: leevi@t...
  • User-agent: Mozilla Thunderbird 0.7.2 (Windows/20040707)

xml schema best practices
thanks for your response michael,

it seems that after all my study and research into xml it is not the 
right form of storgae for the application i wish to create. The info 
would hopefully be accessed numerous times and as more people add their 
business details the xml file will become bigger.. So i guess that a 
relational database od the key afterall.

so now i am armed with this new information and clarity.. i have to ask 
what is xml good for??. If files sizes become a problem when accessing 
the information repeatedly what is a real world situation where xml is 
ideal? possibly storing seperate bits of data for occassional retrieval?

i understand that xml is browser, computer, etc independent and that one 
of its key bebefits in extenability but what good is that if you cant 
share large amounts of data quickly and easily.. will native xml 
databases solve this problem?

as always one answer leads to a 1000 questions...

cheers
Leevi Graham

Michael Kay wrote:

>There's no right answer to this: it depends how you want to use the data.
>Remember that an XML document is not a database. If the document is 1Gb big,
>then opening it (parsing it) every time you want to find out a single phone
>number is going to be very expensive. On the other hand, if it's 1Mb and the
>number of transactions is 1/hr rather than 1000/sec, then it may well be
>viable.
>
>Generally I would implement hierarchic ("contains") relationships like the
>one you describe by using the XML hierarchy, unless this makes the document
>impossibly big. 
>
>If you decide to store the menus separately, either because two pubs can
>have the same menu, or for physical design reasons, there are many ways you
>can represent the relationships. If each menu is in a separate file then
>it's probably most flexible to use a URI. However, where objects have
>natural identifiers like part numbers or personnel numbers, then I prefer
>just to use that identifier, and leave the query logic to work out how to
>find the XML document for a given personnel number or part number. There are
>some people though who insist that the only respectable way to identify
>objects is by means of URIs.
>
>Michael Kay
>http://www.saxonica.com/
>
>
>
>  
>
>>-----Original Message-----
>>From: Leevi Graham [mailto:leevi@t...] 
>>Sent: 16 April 2005 03:41
>>To: xml-dev@l...
>>Subject:  xml schema best practices question.. one 
>>big xml or lots of little components?
>>
>>hi guys this is my first post to this dev-list... hopefully 
>>it wont be 
>>the last...
>>
>>i have a aquestion that has been bugging me for quite some time..
>>
>>i am attempting to create a business directory with xml as 
>>data storage.
>>
>>i wish to create business elements that contain the obvious 
>>information.. address, contact location etc...
>>
>>however the business type may change from retail to professional to 
>>hosplitality....mainly hospitality like pubs and restaraunts..
>>
>>so finally here is my question:
>>
>>*lets say i have a business element that is a restaraunt and that 
>>restauraunt obviously has a menu.. should i include the menu 
>>as a child 
>>element of the business or should i create a seperate xml file called 
>>menus. Also if I do create a menus.xml file that contains the menus 
>>seperatley how will i be able to tell which menu belongs to which 
>>restaraunt..*
>>
>>things to consider my businesses.xml file may eventually contain many 
>>businesses with many menus....
>>
>>hopefully someone can help
>>cheers
>>
>>-----------------------------------------------------------------
>>The xml-dev list is sponsored by XML.org <http://www.xml.org>, an
>>initiative of OASIS <http://www.oasis-open.org>
>>
>>The list archives are at http://lists.xml.org/archives/xml-dev/
>>
>>To subscribe or unsubscribe from this list use the subscription
>>manager: <http://www.oasis-open.org/mlmanage/index.php>
>>
>>
>>    
>>
>
>
>
>-----------------------------------------------------------------
>The xml-dev list is sponsored by XML.org <http://www.xml.org>, an
>initiative of OASIS <http://www.oasis-open.org>
>
>The list archives are at http://lists.xml.org/archives/xml-dev/
>
>To subscribe or unsubscribe from this list use the subscription
>manager: <http://www.oasis-open.org/mlmanage/index.php>
>
>  
>

PURCHASE STYLUS STUDIO ONLINE TODAY!

Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
 

Stylus Studio has published XML-DEV in RSS and ATOM formats, enabling users to easily subcribe to the list from their preferred news reader application.


Stylus Studio Sponsored Links are added links designed to provide related and additional information to the visitors of this website. they were not included by the author in the initial post. To view the content without the Sponsor Links please click here.

Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.