Re: Irony

[Joe <joe@jretrading.com>]

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.

-- 
Joe