Lists Home |
Date Index |
- To: Michael Kay <email@example.com>
- Subject: Re: [xml-dev] xml schema best practices question.. one big xml orlots of little components?
- From: Leevi Graham <firstname.lastname@example.org>
- Date: Sat, 16 Apr 2005 19:51:45 +1000
- Cc: email@example.com
- In-reply-to: <200504160857.j3G8v1w0014934@ensim.smartydns29.com>
- Organization: The Leviathan Project
- References: <200504160857.j3G8v1w0014934@ensim.smartydns29.com>
- Reply-to: firstname.lastname@example.org
- User-agent: Mozilla Thunderbird 0.7.2 (Windows/20040707)
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...
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
>Generally I would implement hierarchic ("contains") relationships like the
>one you describe by using the XML hierarchy, unless this makes the document
>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.
>>From: Leevi Graham [mailto:email@example.com]
>>Sent: 16 April 2005 03:41
>>Subject: [xml-dev] 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
>>i have a aquestion that has been bugging me for quite some time..
>>i am attempting to create a business directory with xml as
>>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
>>things to consider my businesses.xml file may eventually contain many
>>businesses with many menus....
>>hopefully someone can help
>>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
>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