[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Irony



On 20140814_2247+0100, 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.
> 
> -- 
> Joe

In my view SQL is a query language that can do much more than look up
records in a single table. To claim that some init system is superior
to some other init system because it has 'SQL logging' is, as Andrew
said, silly. Almost none of the power of the language is being used in
the init system application. Using the fact of SQL logging as a claim
for systemd is bullet point one-up-manship. The data relation in init
logging is very wide and un-normalized and needs none of the
sophistication of SQL. Of course using SQL makes accessing the data
easier than if one doesn't know or understand SQL, but is that a
reason for choosing systemd over Upstart, for example, or some other
init system whose proponents forgot to list this bullet point in their
presentation? Surely not. Mentioning it is, IMHO, a shoddy debating
ploy and speaks to the intellectual honesty of whoever uses it.

Best regards,
-- 
Paul E Condon           
pecondon@mesanetworks.net


Reply to: