1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

SQL for Smarties

Discussion in 'SQL Exams' started by Crito, Apr 17, 2007.

  1. Crito

    Crito Banned

    505
    14
    0
    I was cleaning up this weekend and happened to stumble upon all three editions of Joe Celko's SQL for Smarties. The third and latest edition was in the back of my car actually. I quite literally never leave home without it. :ohmy

    [​IMG]

    Anyway, for the book collector, they came in three different colors. The first edition (blue) was published in 1995 and there's been a revision every five years since (red in 2000 and green in 2005.) So I expect the fourth edition won't be out until 2010.

    Anyone interested in moving beyond the basics really should have this book in their library.
     
    Certifications: A few
    WIP: none
  2. hbroomhall

    hbroomhall Petabyte Poster Gold Member

    6,623
    115
    224
    I agree completely. I *think* (the book is at home and I'm not) that I have the red one. So I need to get the new one!

    Harry.
     
    Certifications: ECDL A+ Network+ i-Net+
    WIP: Server+
  3. zebulebu

    zebulebu Terabyte Poster

    3,748
    330
    187
    Got the green one!

    Damned if I can find it at the minute though - it must be at work (I'm off sick today for the first time in ten months)
     
    Certifications: A few
    WIP: None - f*** 'em
  4. Crito

    Crito Banned

    505
    14
    0
    I picked up Celko's "SQL Programming Style" the other day too. It's a lot shorter and easier to read. Especially useful for less technical project managers trying to create programming standards and naming conventions.

    Only book of his I didn't like was the data warehousing one. Then again, dimensional modeling /OLAP has changed a lot in the last ten years, whereas relational modeling/OLTP really hasn't -- some might say because it was done right the first time. ;)
     
    Certifications: A few
    WIP: none
  5. Crito

    Crito Banned

    505
    14
    0
    Certifications: A few
    WIP: none
  6. hbroomhall

    hbroomhall Petabyte Poster Gold Member

    6,623
    115
    224
    Another one for the book list - thanks.

    Harry (wondering why his wallet is nearly empty...)
     
    Certifications: ECDL A+ Network+ i-Net+
    WIP: Server+
  7. Fergal1982

    Fergal1982 Petabyte Poster

    4,196
    171
    211
    never heard of it before. sounds like its got high regard round here though. might need to look that out at some point. although for now ill stick the the lower end of the market. not quite at advanced level yet
     
    Certifications: ITIL Foundation; MCTS: Visual Studio Team Foundation Server 2010, Administration
    WIP: None at present
  8. ffreeloader

    ffreeloader Terabyte Poster

    3,661
    106
    167
    Crito,

    I had never seen a Celko book before. Do they cover a specific implementation of SQL, or are they vendor agnostic?

    Out of curiosity, what do you think of Ken Henderson's The Guru's Guide series for T-SQL and SQL Server.
     
    Certifications: MCSE, MCDBA, CCNA, A+
    WIP: LPIC 1
  9. Crito

    Crito Banned

    505
    14
    0
    Joe Celko spent 10 years on the ANSI SQL committee. His books are not implementation specific.
    http://www.celko.com/

    I haven't read any of Ken Henderson's books so can't comment on them.
     
    Certifications: A few
    WIP: none
  10. ffreeloader

    ffreeloader Terabyte Poster

    3,661
    106
    167
    Interesting. I'll have to take a look at them then.

    Thanks, Crito.
     
    Certifications: MCSE, MCDBA, CCNA, A+
    WIP: LPIC 1
  11. Crito

    Crito Banned

    505
    14
    0
    I will say I had to unlearn much of the cr@p other books taught me before accepting what Joe was saying. In fact, he once called me an ID-iot in a Microsoft newsgroup. :ohmy If he hadn't been absolutely right I might still feel insulted.
     
    Certifications: A few
    WIP: none
  12. ffreeloader

    ffreeloader Terabyte Poster

    3,661
    106
    167
    LOL. He sounds a "little" prickly.... :biggrin
     
    Certifications: MCSE, MCDBA, CCNA, A+
    WIP: LPIC 1
  13. Crito

    Crito Banned

    505
    14
    0
    I doubt he has ever been accused of brown-nosing anyways. :blink First encountered him through his column in DBMS Magazine. At the time I was just starting out and the only database book I had read was "Understanding R:Base". I found that book behind some others on a shelf a few years ago and realized my bad design habits had started very early. So while Celko's book are a bit advanced for a novice, I really don't think you can start reading them too soon. Just might take a few years before it all sinks in.
     
    Certifications: A few
    WIP: none
  14. ffreeloader

    ffreeloader Terabyte Poster

    3,661
    106
    167
    I'm going to get one of his books. I like writing sql queries. It seems to be one of the languages that is more of a natural for me.

    Thanks, Crito.
     
    Certifications: MCSE, MCDBA, CCNA, A+
    WIP: LPIC 1
  15. Gaz 45

    Gaz 45 Kilobyte Poster

    404
    4
    39
    I bought the 3rd edition a few months back & it's something I dip into now and again.
    Excellent book, echoing Crito, it's made me unlearn some things & question others that I'd taken as gospel from other sources.

    I've encountered Mr. Celko a few times on the web (although we've not conversed directly), certainly 'prickly' seems a good description! I once saw him rip some DB bods to shreds for using an Identity Int field as a Primary Key (he called it lazy SQL developing, which most people took offence to :) He was right though!)

    Doesn't help that he's a dead ringer for Ming the Merciless...
    :biggrin
     
    Certifications: MCP (70-229, 70-228), MBioch
    WIP: MCDBA (70-290)
  16. Crito

    Crito Banned

    505
    14
    0
    I'm surprised he was so polite about it. I expect he'd say that showed a complete lack of understanding of the difference between logical and physical design. Even if you consider it a surrogate key instead of physical locator, it should become apparent when it takes two joins to return an address that using a stateid and cityid (if not a citystateid too) is just a plain bad idea.
     
    Certifications: A few
    WIP: none
  17. hbroomhall

    hbroomhall Petabyte Poster Gold Member

    6,623
    115
    224
    Depends on your stance on surrogate keys versus natural keys!

    There is a nice comment here, which includes the line:
    which made me smile!

    I'm somewhat agnostic on this - I use either where I feel it is appropriate.

    Harry.
     
    Certifications: ECDL A+ Network+ i-Net+
    WIP: Server+
  18. dmarsh

    dmarsh Terabyte Poster

    3,782
    302
    184
    Personally like most people I expect, I reccomend Surrogate keys unless you have a very specific reason not to. Most databases are utilised by third party applications these days, also businesses tend to change their minds on how they want to operate.

    'Natural keys' don't really exist in reality in my mind, you're not born with a social security Id, its a system implementation detail, a busniess process or system redesign could therorectically alter it at any point. Using a Natural key in such cases where in reality changes are unlikey during the lifetime of the system, and there is a lot of data for instance, is an optimisation. Optimisations should only be used when there is a adequate reason to justify them.

    Frequently these supposed 'Natural keys' are hangovers from old paper based or mainframe systems, theres very little 'Natural' about them, and its quite possible that say an 'order number' or 'manifest id' could be changed at somepoint during the companies operation. Often these were ways of compressing data into a field, so the ID might have multiple bits of information in it, which is a denormalised design probably not best suited to many of todays systems.

    Like many things we are concerned with managing a designing for change, Natural keys form part of the interface to the system so cannot be changed.

    "We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil." (Knuth, Donald.)
     
    Certifications: CITP, BSc, HND, SCJP, SCJD, SCWCD, SCBCD, SCEA, N+, Sec+, Proj+, Server+, Linux+, MCTS, MCPD, MCSA, MCITP, CCDH
  19. Crito

    Crito Banned

    505
    14
    0
    Some people just never learn... even when their convoluted designs result in a dozen otherwise completely unnecessary joins. Looks at the fields you're retrieving from related tables. Chances are they're the natural keys, because the data is meaningless without them. You can't tell someone they live in stateid 14 and cityid 22, especially if they maintain their own cities and states tables with their own autonumbers.

    It's worth pointing out, however, that the rules for good OLTP and OLAP designs are completely different. Another common mistake is mixing the two.
     
    Certifications: A few
    WIP: none
  20. dmarsh

    dmarsh Terabyte Poster

    3,782
    302
    184
    This is denormalisation, theres many ways you can deal with it, you are assuming that the perfromance of the joins are very important. This is not necessarilly the case, you should not prematurely optimise your system.

    Sure an in memory DB with a flat record stucture, single table is gonna perform the fastest, but thats not really what a relational database is about ? By duplicating data you create maintenance and consistency issues, if only an application reads a database who cares if its an Id ? The DBA's can create views, utils and stored procs etc to get whats meaningful to them.
     
    Certifications: CITP, BSc, HND, SCJP, SCJD, SCWCD, SCBCD, SCEA, N+, Sec+, Proj+, Server+, Linux+, MCTS, MCPD, MCSA, MCITP, CCDH

Share This Page

Loading...