Re: simple database solution without root access
On Sun, 6 Jul 2014 21:05:10 -0600
Joe Pfeiffer <joseph@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
Reply to: