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"
]
}
 
Search WWH ::




Custom Search