On Sun, 6 Jul 2014 21:05:10 -0600 Joe Pfeiffer <jos...@pfeifferfamily.net> wrote:
> My typical experience is that when people distinguish "text" vs > "binary" files, they mean the whole file can reasonably be made sense > of in a text editor (that's not a precise definition, of course, but I > think it serves the purpose). When I open an SQLite database I have > handy with emacs, it is rife with nulls and other non-printing > characters. Similarly, when I try to run 'less' on it, the response > is > > babs:506$ less house.db > "house.db" may be a binary file. See it anyway? > > Arguably, as people typically use the distinction, it's not a text > file. Yes, I can extract the text fields, as human-readable ASCII, > but that does not make it a text file. I've always thought that's *exactly* what makes it a text file. If every character's ascii value is between 32 and 126, along with CarriageReturn and Linefeed, it's a text file, regardless of how readable it is, because it's a whole lot more readable than stuff with the upper 129 chars and the miscellaneous control characters (Bell, pagefeed, etc). Now being a text file doesn't guarantee reasonable readability or parsability, as anyone who's looked at M$ XML or ODF can attest. But with a text file, at least you've got a fighting chance to reverse engineer it. Now that we have UDF-8, my definition is no longer valid, but if you've worked a lot with ascii, you kind of "know what I mean". > > >Okay, thinking about it a bit, the lack of delimiters, and the > >puzzling nature of binary zero when trying to read it as text, might > >be what Nuno was referring to. Comma delimited files provide > >visible, understandable delimiters, > > And what just about anybody else would mean by a text file, as well. > > >Oh, and the INTEGER PRIMARY KEY is never readable as TEXT. I think the requirement is that the primary key is meaningless. Whether it's an integer or a string is an implementation detail, I believe. And of course, people violate the requirement all the time: How many use social security number as the primary key (what could *possibly* go wrong?). > > > >For some people seeking to keep data in text format, that might > >disqualify SQLite. Apparently not the OP? > > My impression (I'd have to go back and recheck) is that it > disqualified it for the OP, as well. I don't remember all the OP's requirements, but there's an excellent "database" with the unfortunate name NoSQL, available at http://www.strozzi.it/cgi-bin/CSA/tw7/I/en_US/NoSQL/Home%20Page This database was called NoSQL long before the word "NoSQL" was a buzzword adjective. Basically, what it does is map storage and retrieval commands to sets of Unix directories and commands like cut, sort, grep, awk and the like. NoSQL "tables" are trivial to read with the naked eye, but it gives you Unix-command based readers to put headers and column spacers and the like. It's pretty cool, and it's surprisingly fast. So SQL isn't a requirement, this can be an excellent choice. SteveT Steve Litt * http://www.troubleshooters.com/ Troubleshooting Training * Human Performance -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140707114532.7d9a9...@mydesq2.domain.cxm
