Database Reference
In-Depth Information
A human can look at this information and see quite quickly what information is being communicated. Or maybe
not—is that number in the third column a phone number or a fax number? It might even be the number for a pager.
To avoid this ambiguity, CSV files often have a header field, in which the first row defines what comes in the file.
The following snippet takes the previous example one step further:
Lastname, Firstname, Phone Number
Membrey, Peter, +852 1234 5678
Thielen, Wouter, +81 1234 5678
Okay, that's a bit better. But now assume some people in the CSV file have more than one phone number.
You could add another field for an office phone number, but you face a new set of issues if you want several office
phone numbers. And you face yet another set of issues if you also want to incorporate multiple e-mail addresses.
Most people have more than one, and these addresses can't usually be neatly defined as either home or work.
Suddenly, CSV starts to show its limitations. CSV files are only good for storing data that is flat and doesn't have
repeating values. Similarly, it's not uncommon for several CSV files to be provided, each with the separate bits of
information. These files are then combined (usually in an RDBMS) to create the whole picture. As an example, a large
retail company may receive sales data in the form of CSV files from each of its stores at the end of each day. These
files must be combined before the company can see how it performed on a given day. This process is not exactly
straightforward, and it certainly increases chances of a mistake as the number of required files grows.
XML largely solves this problem, but using XML for most things is a bit like using a sledgehammer to crack a nut:
it works, but it feels like overkill. The reason for this is that XML is highly extensible. Rather than define a particular
data format, XML defines how you define a data format. This can be useful when you need to exchange complex and
highly structured data; however, for simple data exchange, it often results in too much work. Indeed, this scenario is
the source of the phrase “XML hell.”
JSON provides a happy medium. Unlike CSV, it can store structured content; but unlike XML, JSON makes the
content easy to understand and simple to use. Let's revisit the previous example; however, this time you will use JSON
rather than CSV:
{
"firstname": "Peter",
"lastname": "Membrey",
"phone_numbers": [
"+852 1234 5678",
"+44 1234 565 555"
]
}
In this version of the example, each JSON object (or document) contains all the information needed to
understand it. If you look at phone_numbers , you can see that it contains a list of different numbers. This list can be as
large as you want. You could also be more specific about the type of number being recorded, as in this example:
{
"firstname": "Peter",
"lastname": "Membrey",
"numbers": [
{
"phone": "+852 1234 5678"
},
{
"fax": "+44 1234 565 555"
}
]
}
 
Search WWH ::




Custom Search