Thread: The Art of SQL

Hello.

I'm a little more than half way through this book (The Art of
SQL), doing a book review of it for my local LUG.

All in all, it looks like a very good book to me.  I do think that
it should be looked at by novice SQL people, if for no other
reason that to try and keep certain bad habits from forming.

For the novice, I think some other document which talks more about
indexes and foreign keys is needed as well.

One thing which seems to be lacking (from the table of contents, I
don't see it coming up in what I have left to read) is some kind
of discussion as to what kind of stuff should be done outside of
the database.  To me, it just seems reasonable that some tasks
are better suited to the front-end.

Is this a reasonable expectation?  That there are some tasks that
should not be handled inside the database?

Thanks,
Gord

> Is this a reasonable expectation?  That there are some tasks that
> should not be handled inside the database?

Sure. Presentation logic / user interface stuff is the first example
that comes to mind. Although in my experience, a lot of programmers err
in the other direction. The tend to do stuff in the application that
could be better done in the database. I imagine that this is because
they're more comfortable with their native programming language than
SQL.

Drew

On Thu, 2006-08-03 at 08:59 -0600, Gordon Haverland wrote:
> Hello.
>
> I'm a little more than half way through this book (The Art of
> SQL), doing a book review of it for my local LUG.
>
> All in all, it looks like a very good book to me.  I do think that
> it should be looked at by novice SQL people, if for no other
> reason that to try and keep certain bad habits from forming.
>
> For the novice, I think some other document which talks more about
> indexes and foreign keys is needed as well.

That's not the books target market.  If you read the section at the
start "Assumptions made by this book" - it assumes that you're already
pretty darn familiar with databases, SQL, indexing, ect.  I'd imagine
that there are books target at the Novice market that are more
appropriate.

On Thursday 03 August 2006 12:46, Brad Nicholson wrote:
> On Thu, 2006-08-03 at 08:59 -0600, Gordon Haverland wrote:

> > I'm a little more than half way through this book (The Art of
> > SQL), doing a book review of it for my local LUG.
> >
> > All in all, it looks like a very good book to me.  I do think
> > that it should be looked at by novice SQL people, if for no
> > other reason that to try and keep certain bad habits from
> > forming.
> >
> > For the novice, I think some other document which talks more
> > about indexes and foreign keys is needed as well.
>
> That's not the books target market.  If you read the section at
> the start "Assumptions made by this book" - it assumes that
> you're already pretty darn familiar with databases, SQL,
> indexing, ect.  I'd imagine that there are books target at the
> Novice market that are more appropriate.

I looked at that.  I still think that anyone who is writing SQL
will still benefit from reading it.  Or, at least reading the
stuff they understand.  And with time, I'm sure they will have
moments when they realise, "... that's what he meant when he
wrote ...".

Gord

ghaverla@shaw.ca (Gordon Haverland) wrote:
> On Thursday 03 August 2006 12:46, Brad Nicholson wrote:
>> On Thu, 2006-08-03 at 08:59 -0600, Gordon Haverland wrote:
>
>> > I'm a little more than half way through this book (The Art of
>> > SQL), doing a book review of it for my local LUG.
>> >
>> > All in all, it looks like a very good book to me.  I do think
>> > that it should be looked at by novice SQL people, if for no
>> > other reason that to try and keep certain bad habits from
>> > forming.
>> >
>> > For the novice, I think some other document which talks more
>> > about indexes and foreign keys is needed as well.
>>
>> That's not the books target market.  If you read the section at
>> the start "Assumptions made by this book" - it assumes that
>> you're already pretty darn familiar with databases, SQL,
>> indexing, ect.  I'd imagine that there are books target at the
>> Novice market that are more appropriate.
>
> I looked at that.  I still think that anyone who is writing SQL
> will still benefit from reading it.  Or, at least reading the
> stuff they understand.  And with time, I'm sure they will have
> moments when they realise, "... that's what he meant when he
> wrote ...".

My preference would be to have some sort of "starting reference" under
my belt first...  TAOS assumes you already know what a SELECT is, what
a JOIN is, what, in general, GROUP BY does, and such.

But I'm not sure it's needful to get to the "grizzled, wizened old
master" point for the book to become of value.  It does quite a good
job of describing strategies for generating good queries rather than
horrific ones.

And while there is certainly a "knack" for writing SQL, I don't think
it's the same as some of the languages where there needs to be a
tutelage of fighting through writing ghastly stuff before reaching an
epiphany after which it starts to make sense.

For instance, in Lisp, beginners tend to write ghastly, awful stuff
consisting of fighting to pull apart lists, and accomplishing pretty
much complete destruction of them in the process.  Forth beginners do
the same sorts of things with code where you can't see the logic
beside all the "stack smashing."  _Good_ code in these languages has
very little of the "struggle to shove data structures to and fro;" the
experts know how to accomplish things without fighting with the
language.

I suppose an argument can be made that a "TheirSQL" model of the world
involves a naive view where "data smashing" takes place in the front
end application, but I'm not sure how far it would be good to take
that.

It seems to me that TAOS would be worth being exposed to fairly early.
I always preferred seeing *good* references to things, and competent
code samples.  I've never been all that keen on C, but was never
disappointed to have learned it from K&R.  They were very skilled with
it, and their examples demonstrate reasonably skilful use.

I think seeing some examplary code early is *way* better than plodding
through crud before seeing anything good.
--
wm(X,Y):-write(X),write('@'),write(Y). wm('cbbrowne','gmail.com').
http://cbbrowne.com/info/languages.html
Black holes are where God divided by zero.