Is CSV considered a good option against XML and JSON for programming languages?
I generally use XML and JSON (or sometimes a plain text file) as flat file storage. However, recently I came across an CSV implementation in PHP. I generally have seen CSV used for inputs in Excel files though, but I have never used it with programming. Would it be better than XML or JSON in any way?
The answer is, it depends.
CSV is great for certain use cases. For example as a "streaming" format for large datasets, it's easier to stream than XML/JSON, and CSV files take much less storage space. I use it to stream datasets in the gigabyte range where other formats are impractical.
It's also really common in certain industries when dealing with legacy systems and workflows. Try importing JSON into MS Excel.
The ODI recently commented about CSV, calling 2014 "The year of CSV"
For "proper" CSV formatting, consider using the CSV mime type in your HTTP responses.
Most certainly not.
CSV is a table format that maps very well to data sets or other tabular data. But not all data is tabular! Most generally, we want to serialize object graphs. This can be difficult in the following cases:
We further want to be able to reliably de-serialize the objects from our storage format.
Is primarily an extensible markup language. It can be shoe-horned to store general data structures as well. Language support for IDs means that complex graphs can be created, although it's best used for trees. A document can be tested for correctness against a specification. There are various problems with this format that can make it impractical, such as the extreme verbosity.
Is primarily a way to store simple object trees. There is no support for general graphs. JSON has no concept of type beyond primitives string, integer, float, boolean, null and the collection types array and object.
Most easily understood as an extension of JSON. Has a notion of aliases that allow object graphs of arbitrary complexity to be created. Has a concept of metadata like tags that can be used for proper typing.
Has nothing, except a single table. If we want to store object graphs, we would have to use a schema like
#ID,Type,Field1,Field2,...,FieldN
1,String,foo
2,String,bar
3,Array<String>,1,2
There are many dialects of CSV that disagree on delimiters, line terminators, quoting, escape characters, and many other issues that make it unsuitable for general (binary) data. All of this makes it rather difficult to process CSV data.
So basically, easy things are difficult or impossible with CSV when using it as a general serialization format.
This criticism does not apply when using it to store truly tabular data like time sheets or a series of measurements. Here, CSV (often in the variant of tab separated values) is usually more compact and easier to use than the other data formats.
I'd also have to say that it depends on what you are trying to achieve. For many problems it doesn't matter much what you choose if the problem is small enough and your choice fits well with the existing system.
Taking a legacy system and trying to shoehorn in a new format can sometimes be a problem as you've introduced more complexity and have a new input system to debug. I've seen this a lot when new people prefer something different than what exists, or when a new format appears and they want to experiment with it. This may or may not be a good idea, it depends on circumstances.
Years ago I worked on a research graph database system that depended on CSV files of various formats. The CSV file importer would build graphs for us and it had many years of work done to debug and optimize the code. It was both fast and flexible and we'd happily use it to bootstrap large research projects. When XML appeared on the scene we added an XML importer but it was not necessarily an improvement in terms of speed or expressing complexity, and certainly XML was not any better at expressing graph structures than CSV. JSON is a lot nicer (and terser) than XML but is similar in many respects so I'd expect a similar result when creating an new importer on that system.
At one point in time we had a customer bring in a massive amount of data in (as we called it) "cobol" format, files with lines of variable length containing markers that indicated how to interpret the bytes that followed on that line. It came from a time when storage was expensive so compactness was a requirement. We imported that data by converting it into CSV format on the fly and feeding it into the CSV importer. That was easy to do and minimized the amount of debugging and maintenance, which are good things. If we had to import that kind of data all of the time we might have built it into the system directly to get performance and efficiency gains.
So, it depends on what you're doing and on what the underlying system does. In my example the CSV importer was solidly engineered and dependable. I'd hesitate to tell you that one format was better or worse without understanding what is going on in the other layers I am building. I love JSON and prefer it, but I know that given certain complex data structures and large enough data sets, CSV files can be made to work very well, too.
No.
CSV is not really a single format. There is a wide variety of styles for escaping, separators, and other formatting issues that many CSV files in the wild have.
If you are going to be using this as a flat file storage, using JSON will serve you much better. JSON maps to and from objects with much less hassle than you will have kludging CSV to do so.
I would strongly advise against it. I might be OK to output CSV at some point (if the user requests it). But it is a bad fit for storage / import purposes. This is mostly due to the fact that "CSV" is very ill-defined. Does the "C" indicate "comma" or "character" separated? How do you treating text strings which are containing escape characters like "? Every damned CSV implementation treats escape characters etc. differently, which leads to files which can be ex- but not imported etc.
Excel is a good demonstration: In the english version it uses "," as separator. In Germany, it uses ";". So a german version chokes on english CSV files, and vice versa ...
It's main strength is human readability, which should not be discounted. But I would not rely on it as a storage format, it is too brittle for that purpose. If you have to export files for humans, you might use CSV but even then I would try to use a library which writes to xlsx files (they are freely available).
In General NO. Why? JSON and XML are there basically to get rid of the dreaded CSV. They're the structured approaches of what has been done unstructured with CSV for a long time. Yes, there are some use-cases where CSV is still prefered but in general in 9 out of 10 cases you're better off not using CSV.
