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

Re: Flatter is Better (part two)

  • From: Ghislain Fourny <ghislain.fourny@28msec.com>
  • To: "Costello, Roger L." <costello@mitre.org>
  • Date: Tue, 2 Dec 2014 13:56:11 +0100

Re:  Flatter is Better (part two)
Hi Roger,

I have two thoughts on this:

1. I think normalization or denormalization has a wider scope than exchanging data. In NoSQL data stores, it is very common to denormalize data, because queries can run much faster (less joins). You exchange once (e.g., ETL), but you query many times.

2. Also, I would not be so sure that the association denormalized=flat, normalized=fat always holds. Actually, I would even have spontaneously made the opposite binding: consider flat data (that you could store in a relational table) that is, say, in third normal form (3NF), and you can then denormalize it by nesting pre-computed joins, i.e., making it fat.

Just two quick thoughts.

Does it make sense?

Kind regards,
Ghislain


On Tue, Dec 2, 2014 at 11:30 AM, Costello, Roger L. <costello@mitre.org> wrote:

Hi Folks,

 

The flat design is about creating XML documents that consist of a long series of standalone components:

 

 

A component in the document can be combined with other data (mashup):

 

Let’s take a concrete example to compare the flat design versus the fat design.

 

Here is a flat design:

 

<Iowa>
   
<house>
       
<street>1009 Arlington Court</street>
       
<city>Davenport</city>
       
<style>Ranch</style>
       
<porch>open</porch>
       
<year-built>1951</year-built>
       
<square-feet>1700</square-feet>
   
</house>
   
<house>
       
<street>1008 Arlington Court</street>
       
<city>Davenport</city>
       
<style>Ranch</style>
       
<porch>closed</porch>
       
<year-built>1955</year-built>
       
<square-feet>1850</square-feet>
   
</house>
    ...
</Iowa>

 

The document consists of a long series of standalone <house> components. Any of those <house> components could be mashed-up with other data, e.g., mashup a <house> component with a <GPS> component.

 

Here is a fat design:

 

<Iowa>
   
<city name="Davenport">
       
<street name="Arlington Court">
           
<house>

               <street-number>1009</style>
               
<style>Ranch</style>
               
<porch>open</porch>
               
<year-built>1951</year-built>
               
<square-feet>1700</square-feet>
           
</house>
           
<house>

                <street-number>1008</style>
               
<style>Ranch</style>
               
<porch>closed</porch>
               
<year-built>1955</year-built>
               
<square-feet>1850</square-feet>
           
</house>
       
</street>
        ...
   
</city>
   
<city name="Cedar Rapids"> ... </city>
    ...
</Iowa>

 

The flat design and the fat design are radically different!

 

In the fat design the houses have been grouped into streets and the streets have been grouped into cities. The street name data has been removed from each <house> and also the city name data has been removed from each <house>. Consequently, each <house> is no longer a standalone component. House data is now fragmented, scattered over the document. The ability to do mashups has been lost (or, at least, greatly hampered). The fat design has normalized the data and, as I argued in my last message: Normalization is horrible for data exchange formats.

 

It’s best to exchange the data in the flat design. Consumers can transform it into the fat design, if needed.

 

Recommendation: When designing a data exchange format create a flat design.

 

Comments?

 

/Roger




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]


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.