On Fri, Aug 15, 2014 at 6:05 AM, AW <debian.list.trac...@1024bits.com> wrote: > On Thu, 14 Aug 2014 14:14:28 -0600 > Paul E Condon <pecon...@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. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/caar43iogaf7-j1yazy-xhwvxc_y4+pgtmg4jxlmuoz0ypd3...@mail.gmail.com