CSV as a Data Source
31–40 of 53 posts
Re: CSV as a Data Source
#32Data isn't "locked up" in CSV, rather it is available in CSV. CSV is one of the most open things possible. As a programmer I do a lot of one-time makeshift data reports for other people, and I always use CSV (or precisely, tab separated) because that's what every program happily emits and consumes. If it does not, it's trivial to transform thanks to UNIX sort, awk and uniq.
If I were to build a MVP for any type of data charting or visualization or analysis the first data format that I would think of supporting would be CSV.
Compare this to connecting to a customer's database directly. You can refresh your (cached) chart data on your own schedule and the customer doesn't need to be involved at all.
Oh and if anyone is thinking, "Yeah but I can schedule a cron job to extract the CSV file and publish it every X minutes", yes you could do that but again that's work for the customer. If the pitch is "sign up, plug in to your database, and boom charts!" there really should be a "schedule automated cron job" component.
All that aside, it is useful to be able to manually add data like this. Particularly for static data where the manual work is infrequent.
Re: CSV as a Data Source
#33Data isn't "locked up" in CSV, rather it is available in CSV. CSV is one of the most open things possible. As a programmer I do a lot of one-time makeshift data reports for other people, and I always use CSV (or precisely, tab separated) because that's what every program happily emits and consumes. If it does not, it's trivial to transform thanks to UNIX sort, awk and uniq.
Once your CSV (or TSV) files start having quoted fields, they become very tricky to parse using standard multi-purpose tools like sort, awk, & uniq. It's hard enough when you have delimiters in quoted fields, but dealing with quoted newlines starts to become unreasonable, especially for line-based tools. CSV files, as you say, are absolutely wonderful to create. Problems come up when you try to parse files other peop…
Re: CSV as a Data Source
#34- Header line or none?
- "\n" or "\r\n"?
- Is there a newline at the last line? How about two?
- Escape quotes with doubling or backslash? How about both in the same file? How about both, inconsistently, in different fields? How about quotes including a newline and commas?
- Strings always quoted? Only if necessary? Is ,, a null or an empty string, or an error?
- How about mixed line lengths? Are missing trailing entries nulls? How about multiple data types in a file, with the first field being type, and line length only fixed per type?
I have generally found "TSV with a rule that data cannot represent tabs or newlines, period" as vastly superior.
Re: CSV as a Data Source
#35Re: CSV as a Data Source
#36CSV is the biggest pile of nuisance you'd never expect from a seemingly simple data format. - Header line or none? - "\n" or "\r\n"? - Is there a newline at the last line? How about two? - Escape quotes with doubling or backslash? How about both in the same file? How about both, inconsistently, in different fields? How about quotes including a newline and commas? - Strings always quoted? Only if necessary? Is ,, a nu…
Those aspects are defined in RFC 4180 - just a lot of systems don't bother. How would you define a simpler data format?
Re: CSV as a Data Source
#37Data isn't "locked up" in CSV, rather it is available in CSV. CSV is one of the most open things possible. As a programmer I do a lot of one-time makeshift data reports for other people, and I always use CSV (or precisely, tab separated) because that's what every program happily emits and consumes. If it does not, it's trivial to transform thanks to UNIX sort, awk and uniq.
Once your CSV (or TSV) files start having quoted fields, they become very tricky to parse using standard multi-purpose tools like sort, awk, & uniq. It's hard enough when you have delimiters in quoted fields, but dealing with quoted newlines starts to become unreasonable, especially for line-based tools. CSV files, as you say, are absolutely wonderful to create. Problems come up when you try to parse files other peop…
Plus you've got encodings. If you're accepting CSVs from users, they'll generally come from Excel, which will produce different encoding in different circumstances.
Re: CSV as a Data Source
#38Earlier quoted context omitted.
From what I understand, you're basically right, but you're basically right only in a sense that that's what most people do. There's no "CSV Data Format" spec. It's all just what most people agree on, most of the time. Unless someone has another idea.
text/csv is defined in RFC 4180: https://tools.ietf.org/html/rfc4180
Re: CSV as a Data Source
#39CSV is the biggest pile of nuisance you'd never expect from a seemingly simple data format. - Header line or none? - "\n" or "\r\n"? - Is there a newline at the last line? How about two? - Escape quotes with doubling or backslash? How about both in the same file? How about both, inconsistently, in different fields? How about quotes including a newline and commas? - Strings always quoted? Only if necessary? Is ,, a nu…
TSV has all those same issues. However, you just have less frequent need of a tab, so most of the escaping edge cases never come up. Those aspects are defined in RFC 4180 - just a lot of systems don't bother. How would you define a simpler data format?
TSV is streamable and minimally wasteful, I rather approve of it. Netstrings are better though if having sized data and nested data is needed. They are proof against all the ills of quoting and escapes.
Re: CSV as a Data Source
#40CSV is the biggest pile of nuisance you'd never expect from a seemingly simple data format. - Header line or none? - "\n" or "\r\n"? - Is there a newline at the last line? How about two? - Escape quotes with doubling or backslash? How about both in the same file? How about both, inconsistently, in different fields? How about quotes including a newline and commas? - Strings always quoted? Only if necessary? Is ,, a nu…
TSV has all those same issues. However, you just have less frequent need of a tab, so most of the escaping edge cases never come up. Those aspects are defined in RFC 4180 - just a lot of systems don't bother. How would you define a simpler data format?