Re: Irony

[Joel Rees <joel.rees@gmail.com>]

On Fri, Aug 15, 2014 at 6:05 AM, AW <debian.list.tracker@1024bits.com> wrote:
> On Thu, 14 Aug 2014 14:14:28 -0600
> Paul E Condon <pecondon@mesanetworks.net> wrote:
>
>  > Andrew, are your cookies virtuous (lo-cal) or virtual? ;)
>
> Neither.  I prefer homemade chocolate chip using 1/2 cup butter and 1/2 cup
> Crisco... Just like my grandmother used to make...
>
>  > Comments (opinion) supporting your position that SQL logging is silly.
>  >
>  > It is my understanding that SQL is a query language that is designed
>  > to query (and update) a *relational*database*
>
> Logging data are 100% relational.  In fact, everytime someone uses grep, tail,
> head, cut, and awk to search through a log file -- they demonstrate that the
> log data are relational.

When you think like that, this email is relational.

But I can buy that much functionality without bothering with any index
tables or other database application overhead.

When you're grep- or sed-searching a textual log file, you don't care
whether all the log entries fit any particular relation or structure
definition, and you don't have to think sideways to search on the
keywords buried in the text of the actual log entry.

When you're dumping log data to a pure text log file, you don't care
whether there's a server or even a functioning SQLite
library+subsystem on the other end. If your file system, at least, is
functioning, you're log gets recorded.

> http://web.mit.edu/11.521/www/lectures/lecture10/lec_data_design.html
> and.
> http://ocw.mit.edu/courses/electrical-engineering-and-computer-science/6-830-database-systems-fall-2010/lecture-notes/

Wow. You can find entry-level textbooks.

Have you ever considered how many bad database designs can be crammed
into the relational model?

Not saying the relational model is any worse than any other database
model, but the mere fact that a design can be made does not mean it is
a particularly functional design, nor does it mean that it accurately
represents the data, any particular meaning of the data, or any
particular use of the data.

> A syslog is close to very definition of relational data with the primary key
> being the timestamp and/or the "facility" in one large table [not the best
> design] --- or better primary key being the timestamp and/or generated uuid and
> the facility being the table...

syslog is not a particularly good example of a logging facility. But
even within that, you can't seem to see the trees for the forest, if
you'll pardon me. (We used to understand that seeing the forest
required seeing the trees. These days, the champions of the white
paper view of the universe seem to be winning.)

> However, as I stated previously, systemd seems fine to me... and the old
> sysvinit have sql export already -

So that by-the-white-paper managers can get their fix, basically.
Exporting it doesn't mean you have to delete the original, but that's
beyond the point.

> so, obivously lots of people thought and
> presumably still think log data is handy in an sql database.

Handy to people who want everything in SQL format is fine, after the fact.

> http://www.rsyslog.com/doc/rsyslog_pgsql.html
> QED.

QED what?

The problem with OS-level logging that you seem to be missing is that
the OS sometimes gets into very undefined states.

Plaintext logs can often still be written when the file system is only
partially functional, and might even be viewable on a console even
with the file system completely bombed.

Even with SQLite, you have to have a properly functioning file system,
in addition to a properly functioning SQL subsystem of some sort. Not
requiring a server does not mean not requiring stable state or the
library code to maintain state.

(And when you try to reconstruct a database that has been dumping to a
bombed file system, what tools do you use? You start with plaintext
tools to find the wayward writes. Then you have to use special
maintenance-only database tools that never use. So you are probably
learning how to use them as you go, when any mistake could cost you
the farm.)

The fundamental tools you use are plaintext. And if you are an admin
worth your pay, you know how to deal with plaintext. Structure is what
you give the data after you have the data safely stored away.

-- 
Joel Rees

Computer memory is just fancy paper,
the CPU is just a fancy pen.
All is text,
flowing freely from the past to the future.