Re: Irony

[Jerry Stuckle <jstuckle@attglobal.net>]

On 8/14/2014 5:47 PM, Joe wrote:
> On Thu, 14 Aug 2014 14:14:28 -0600
> Paul E Condon <pecondon@mesanetworks.net> wrote:
> 
>>
>>
>> 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* that has been designed
>> according to design rules for which there is a vast how-to
>> literature. Usually the goal is a database about a business firm and
>> its customers, suppliers, employees, and stock holders. 
>>
>> For SQL logging to be useful, it seems to me, there should be a
>> properly designed *relational*database* of the internal state of a
>> computer and its relationship to its users, and to the resources under
>> its control.
>>
>> Are there such designs? Something that a sysadmin can buy, and/or
>> download, from a reliable source and install and get working with
>> minimal effort? Something that he can just do without management
>> thinking he is exceeding his job authority? I think not.
>>
>> Therefore I conclude that SQL logging will not be used except in very
>> large, very stable organizations, and should not matter in the context
>> of Debian and its future. If it does happen in Debian, it will be just
>> another downloadable .deb package, not a major shift in the nature of
>> the Debian community or its relations with the rest of human society.
>>
>> Who knows of an Entity-Relationship diagram for a POSIX system wherein
>> the updates of data meet the 'ACID' criteria? What will happen if a
>> logged transaction violates an integrity constraint that is required
>> by the data model? 
>>
>>
> 
> I think you're overcomplicating it. SQL works fine on just a single
> table. If you have a standard log format, in that there are
> well-defined fields, even if not all logs have the same fields, then
> SQL can be used to select and sort log entries on any criterion. At
> that level, SQL is a pretty trivial but powerful language to use.
> 
> It is certainly used for logs in Windows, though unfortunately using
> the massively heavyweight SQL Server. Exchange, the MS email server,
> stores all email in an encrypted relational database, because again,
> emails have well-defined fields, and searching is easy. Before anyone
> jumps in, searching in Exchange uses LDAP, because it is 'integrated'
> with Active Directory, but the underlying database is a JET relational
> one, operating on SQL, much like the native Access single-file database.
> 
> My home databases are all SQL with one exception (email clients can use
> LDAP address books but not SQL ones, which is a pain). They are mostly
> single tables with a few small auxiliary lookup tables, and SQL is
> trivial to use from PHP or perl via Apache, or by any ODBC client
> directly. As it's a standard TCP protocol, it can be forwarded over
> ssh. One of my databases relates to customer work, and I can open it
> anywhere with a LibreOffice Base application over ssh from my laptop.
> 
> SQL server backups are plain text, dumped out of the server in the form
> of SQL statements, which can be imported by any other SQL server
> (possibly with a bit of messing about with line endings, character
> encoding, etc). It isn't as transparent and flexible as plain text
> files when you're logged into the computer which stores them, but it's
> the next best thing, and its client-server nature gives it other
> flexibilities that plain text files cannot offer, in addition to more
> powerful search facilities when grep isn't quite enough.
> 

Sure, applications can use SQL Server or other SQL databases.  But what
if your SQL Server is not running for some reason or another?  Maybe a
corrupt database prevents it from starting, for instance.  What is the
kernel to do?

And while you can access it with PHP, perl and almost any other
language, it's not always so easy to do so.  And simple SQL statements
are OK - but what if you want to search for messages which contain
"abc", "def" and "ghi", in any order?  This can easily be accomplished
with chained grep's, for instance.  But it's not so easy with SQL (and
the actual SQL you use may vary depending on the database you are using).

Yes, Windows uses SQL for logging.  But when was the last time you were
able to boot into a Windows command line (in SAFE mode) and look at the
log?  Maybe never?  I do this a LOT on my servers.

And yes, you can export from SQL Server - but you may have to go through
a lot to import to another SQL database.

I have used both SQL and grep for many years.  When searching text like
logs, I find it much easier to use grep.  I can even open the log in
vim, search for what I want and the surrounding log entries are right
there.  You can't do that with one SQL statement.

There are people that think SQL is slicker than snot on a doorknob.
It's great for what it's designed for (relational data).  But it just
doesn't work as well as plain text files for things like logs.

Jerry