Keeping up to, and down with, Date

  • Comments posted to this topic are about the item Keeping up to, and down with, Date

    Best wishes,
    Phil Factor

  • Back in the early days of SQL server, we'd pickup Sybase SQL Server books. Seems finding MSFT SQL Server books were rare, outside of the printed manuals. And the corollary: It's really difficult to discard old tech books. They all have some golden nuggets.

    The more you are prepared, the less you need it.

  • Still keep and reread my old "general" performance books as well as ones written 10-15 years ago by various database and OS experts. They really apply to any database/OS even though the tools may be different.

  • @andrew..Peterson

    There was a book that Microsoft gave away with SQL Server in the early days that was wonderful. It used _PUBS database for all the examples and was very clear. I think it must have come from Sybase originally. I loved it but copies were hard to come by and eventually someone took it. I'd love a copy.

    @kfries.

    I have a copy of Ken England's SQL Server 2000 performance Optimization and Tuning Handbook It is clear and sensible, and gets to the point. Sure, quite a bit has changed, but the general principles are the same. I still refer to it.

    Best wishes,
    Phil Factor

  • I remember the PUBS database. I used it to write an article for SQL Server magazine.

    I've have quite a few Chris Data books, no more early SQL Server books, except for the box, manuals, and disk/floppies for SQL Server 4.21. Not sure why I kept that.

    The more you are prepared, the less you need it.

  • It is worth reading some books again. I am currently rereading "The Mythical Man-Month: Essays on Software Engineering". Coincidentally I have even just got off a call to a PM where I quoted Brookes. It seems that some things never change.

    Gaz

    -- Stop your grinnin' and drop your linen...they're everywhere!!!

  • I don't know how you do it. I can't read tech books without falling asleep. I use them as reference to learn something new or relearn something I've once learned but haven't used regularly. Even then, I'm more likely to read blog posts or SE question/answers on the topic I'm struggling with currently. I don't think I even own any tech books anymore.

  • The Mythical Man Month can be found here:

    https://archive.org/stream/mythicalmanmonth00fred/mythicalmanmonth00fred_djvu.txt

    https://archive.org/stream/mythicalmanmonth00fred/mythicalmanmonth00fred_djvu.txt

    Any guesses on the title of the Pubs related book?

    412-977-3526 call/text

  • The other day while cleaning out the garage, I stumbled across a box full of old IT books. One was a late 1980s era edition of "Oh! PASCAL!" by Doug Cooper, which was my first programming language and book. Others were Networked dBase III Programming, an early 90s era edition of Computer Shopper magazine, and even a Commodore 64 User's Guide from 1985. It was kind of like bumping into a few friends from high school, and I spent the rest of the afternoon browsing through them and reacquainting myself.

    "Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho

  • My bedrock performance books were initially Neil Gunther and Cary Millsap's tomes. Cary's book on Oracle performance was a breakthrough in performance tuning using wait events and given the number of wait events now in SQL Server, the methodology still applies.

    Neil simply rocks.

  • I still totally rate Bertrand Meyer's Object Oriented Software Construction (1988 if I recall correctly). Particularly the chapter (8?) based on his seminal paper defining Design by Contract.

    Gaz

    -- Stop your grinnin' and drop your linen...they're everywhere!!!

  • Programming the 6502, Kernighan & Ritchie Programming in C.

    Simpler times but with an emphasis on writing efficient code. Quite a few of these books lay down the principles that we use today. This makes them surprisingly relevant today.

  • Phil,

    The name of the this article "Keeping up to, and down with, Date"; I get that it's a pun making reference to the mathematician, relational database pioneer, and author Christopher J. Date, and also perhaps an even more oblique reference to the play, "Keeping Down with the Joneses". If so, then that's pretty clever.

    🙂

    "Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho

  • Eric M Russell - Monday, January 9, 2017 3:33 PM

    Phil,The name of the this article "Keeping up to, and down with, Date"; I get that it's a pun making reference to the mathematician, relational database pioneer, and author Christopher J. Date, and also perhaps an even more oblique reference to the play, "Keeping Down with the Joneses". If so, then that's pretty clever. 🙂

    I wondered if Date was intended to suggest CJD, but then thought that Phil would never want to get down to that level let alone keep down there.  I may of course be wriong.   But after suffering all his nonsense, things like

    "NULL - you can't have NULL, because as soon as you need one sort of NULL you need a second sort and one you have two sorts of NULL it's easy to prove you need an infinite number of sorts"
    Which was pure bullshit

    "there's no need for NULL, you can always do the same thing by having a default value for the column" 
    That's going to work beautifully for the inner join of two derived tables each constructed by outer joins between base tables, isn't it? maybe you can get around it if you can find a value you can safely exclude from the original domain (sometimes difficult), and ensure that it doesn't combine in any sort of sane manner with other values in the domain (usually impossible) or values in other domains which can be combined with operators (almost always impossible even if the usually-impossible in domain requirement isn't), and are prepared to write extra SQL to exclude cases of a match on the default and replace all the arithmetic and comparison operators with code to handle these defaults.  So that was also quite clearly pure bullshit

    "1 NF is a bad idea because because the intersection of a row and a column shouldn't be restricted to a things that the database sees as single value, it could be something seen as a list of values or as a set of values or as whatever you like"
    I guess I don't have to say it a third time?

    and seeing the wonderful idiot he made of himself in the published debate with Codd,
    I don't think I'll ever trust anything he said or wrote, and keeping down with CJD would in my view be insane.

    Yes, he wrote some quite intelligent stuff  as well, but most of it was tainted by the sort of nonsense I've referred to.  The worst of it is that people who don't understand the relational model have taken his rubbish to heart and we have extreme anti-null people and anti-atomicity people participating in this site.  Sensible people say "try to avoid NULL but if you can't don't screw up by not using it", which is very anti-CJD and very pro-Codd; and sensible people also say "we don't care if the application which gets the value from the database sees what it's got as a complex object with many components as long as the database sees it as a simple atomic object that has no structure but only attributes discoverable by the functions built in to the SQL (or QEL,or whatever our database uses for queries) language" which is very anti-Date, and very pro-Codd (who would of course have voted for "whatever" rather than for SQL).

    Tom

  • Yes, I must admit that Chris Date was one of the thoughts in my mind when I wrote this. I'd just been rereading his textbook on SQL. I must admit that I am in favour of Codd's orthodoxy. I've never had any serious objection to it and found no flaw in it over may years of working with RDBMS. I enjoy reading Chris Dates work though. He remains the official opposition to SQL, and I suppose someone has to do it.

    Best wishes,
    Phil Factor

Viewing 15 posts - 1 through 15 (of 18 total)

You must be logged in to reply to this topic. Login to reply