Beta

Slashdot: News for Nerds

×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

The Art of SQL

samzenpus posted more than 8 years ago | from the learn-all-about-it dept.

225

Graeme Williams writes "One difference between SQL and a conventional procedural programming language is that for SQL there's a bigger gap between what the code says and what the code does. The Art of SQL is the opposite of a cookbook – or rather it's about cooking rather than recipes. It's not a reference manual, although there's plenty to refer back to. It's an intermediate level book which assumes you know how to read and write SQL, and analyzes what SQL does and how it does it." Read on for Graeme's review.

I guess it's normal for an intermediate text to present a number of serious examples, the idea being that the code from an example can be applied to roughly similar problems with roughly similar solutions. I think Faroult's goal is both more abstract and more ambitious. He wants to expand your ability to navigate among and analyze alternative SQL statements with more confidence and over a larger range. This isn't so much a book about SQL as it is about thinking about SQL.

There's almost no chance that the SQL examples in the book will be directly applied to a real problem. The examples are relevant at one remove: What does thinking about this example tell me about thinking about my current problem? So the book doesn't come with downloadable samples. There's no point.

The first few chapters of the book lay a foundation for the rest. As each brick in this foundation is placed, it sometimes feels as though it's placed firmly on your head. Think about indexes ... whack! Think about join conditions ... whack! These chapters have very few examples – the goal is to force you to think through queries from first principles. It's more effective (and less painful) than it sounds.

These introductory chapters cover how a query is constructed and executed, including how a query optimizer uses the information which is available to it. Faroult discusses the costs and benefits of indexes, and the interaction of physical layout with indexes, grouping, row ordering and partitioning. He also explains the difference between a purely relational query and one with non-relational parts, and how such a query can be analyzed in layers. Chapter 4 is available on the book's web page. It will give you a good idea of the style of the book, but not of the level of SQL discussed – the longest example in the chapter is just 15 lines.

Chapter 6 presents and analyzes nine SQL patterns, from small result sets taken from a few tables, to large result sets taken from many tables. The chapter falls roughly in the middle of the book, and feels like its heart. Prior chapters have built up to this one, and subsequent chapters are elaborations on particular topics. The theme of the book, to the extent that it has one, is that details matter. Different SQL statements can be used to produce the same result, but their performance will be different depending on details of the data and database. A change to the database structure, such as adding an index, might improve performance in one set of circumstances, but make it worse in another. The case analysis in this chapter will make you more sensitive to details in query design and execution.

The authors almost never mention particular database products. Their justification is that any absolute statement would be invalidated by the next release, or even a different hardware configuration, and anyway, that's not the business they're in. But sometimes this can go too far. The phrase "A clever optimizer ... will be able to" is too hypothetical by half. Is this an existing hypothetical query optimizer, or a vision of a future optimizer? Or the optimizer of one hypothetical database product and not of another? I suspect that Faroult knows and is simply being coy. It's just unhelpful not to tell us what existing databases will do, even if depends on the release or the hardware.

Faroult does this because he's not much interested in telling you what actually happens when a particular SQL statement is executed by a particular database. If the authors wanted a cute title for the book, I'm surprised they passed over The Zen of SQL Maintenance. When you look at an SQL statement, Faroult wants you to see what other SQL statements would do under other circumstances. He literally wants you to see the possibilities.

The second half of the book continues the analysis of chapter 6 into special cases, such as OLAP and large volumes of data, monitoring and resolving performance issues, and debugging problematic SQL.

Chapter 7 discusses tree-structured data, like an employee table with a column for the employee's manager. Faroult likes his own solution best, but presents an alternative approach by Joe Celko clearly enough for you to explore that as well.

Chapter 8 includes a series of examples of SQL and PHP. For anyone like me who spends more time in various programming languages than in SQL, this chapter is a small gem. It nicely illuminates the care needed in deciding what happens in code and what happens in SQL.

Chapter 9 addresses locking and concurrency, as it applies to both physical and logical parallelism. Transactions are included, but the discussion is just one part of a 20-page chapter and seems thin.

The Art of SQL is very clearly written. Whether it is "easy" will depend on how comfortable you are with SQL. This book is targeted at (page xi) "developers with significant (one year or, preferably, more) experience of development with an SQL database", their managers and software architects. I have months of experience spread over a decade or more, so I'm nominally outside the target audience. I found the SQL examples and discussion clear once I had a chance to let them sink in. If you're working with SQL regularly, they'll be perfectly clear.

The graphs let down the otherwise high quality of the book. For example, Figure 5-3 shows a rate (higher is better) but the legend says "Relative cost" (higher is worse). Figures 9-1 through 9-3 on facing pages 228 and 229 show response time histograms for three different query rates but don't show what the rates are. The x-axis of Figure 10-1 seems to be calendar time, but it's decorated with a stop watch icon. And as a representative of rapidly aging boomers with rapidly deteriorating eyesight, could I beg book designers not to put figure legends in a smaller font than the text of the book? Diagrams should be simple and clear, not something to puzzle over.

This is a book to conjure with, but it's not a book for everyone. Some people may find it too abstract, with too much discussion of too few examples. If you're completely new to SQL, the book will be hard going. If you have very many years of experience with SQL, it's just possible that you won't find anything new in the book, although I expect you'll find a lot to think about. For anyone in between, The Art of SQL is a excellent way to improve the way you attack problems in database and query design.


You can purchase The Art of SQL from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

cancel ×

225 comments

So According to the blurb... (0)

Anonymous Coward | more than 8 years ago | (#15489490)

... the reviewer has abolutely no idea what he just read?

Re:So According to the blurb... (0)

Anonymous Coward | more than 8 years ago | (#15489513)

"One difference between SQL and a conventional procedural programming language is that for SQL there's a bigger gap between what the code says and what the code does.

Just from reading that, I can tell that the reviewer knows exactly what he's talking about. Why I say this? Because I've worked with SQL myself. SQL is a language invented, by IBM, from a different time when there wasn't such a history of Computer Science.

Re:So According to the blurb... (0, Flamebait)

Shut the fuck up! (572058) | more than 8 years ago | (#15489527)

Christ, I think I've met a genius. Are you one of the 5 kings of Europe that owns an SQL database?

Re:So According to the blurb... (0, Funny)

Anonymous Coward | more than 8 years ago | (#15489598)

He doesn't really have that much clue ...

snippet:

If you have very many years of experience with SQL,


you can't have _many_ years experience, you may just have years of experience.
many years sounds like 20 or 25 ... but emm, dudes, sql wasn't around yet.

tomorrow we'll discuss C# with the developers who have 10 years of experience.

Re:So According to the blurb... (0)

Anonymous Coward | more than 8 years ago | (#15489859)

Bullshit... I was working with SQL on DB2 in the early 80's.

Re:So According to the blurb... (2, Informative)

Anonymous Coward | more than 8 years ago | (#15489902)

umm... dude? SQL has been around since the mid 50's. A guy at IBM developed it. Now, it was made before high level languages, and brother, that's why SQL is anchronistic and irreperably flawed.

Yep, i said it.

Re:So According to the blurb... (1)

AutopsyReport (856852) | more than 8 years ago | (#15490105)

SQL was created in the 1970's [wikipedia.org] . So it is possible to have many years experience with SQL. Heck, it was adopted as a standard in 1986. That is plenty of time to accumulate much experience with SQL.

Re:So According to the blurb... (0)

Anonymous Coward | more than 8 years ago | (#15490235)

I've been working with SQL since 94 (12 years) - Microsoft SQL Server 4.2 on OS/2, no less. I know that SQL was around for quite a while before that because the standard used then was SQL-89.

CJ Date's book was published in 1975, so I'm sure it was around before then, too. http://dblp.uni-trier.de/rec/bibtex/books/aw/Date7 5/ [uni-trier.de]

Layne

SELECT * FROM first_post; (-1, Offtopic)

Anonymous Coward | more than 8 years ago | (#15489495)

n/t

Re:SELECT * FROM first_post; (5, Funny)

Anonymous Coward | more than 8 years ago | (#15489727)

+---------+
| You     |
+---------+
| Fail It |
+---------+
1 row in set (0.08 sec)

Re:SELECT * FROM first_post; (0)

Anonymous Coward | more than 8 years ago | (#15489743)

damn... I always read GOLD when I have no mod points... mod parent up!!! Funny++

Re:SELECT * FROM first_post; (1)

pdpTrojan (454023) | more than 8 years ago | (#15489950)

hahahahha best post ever

Re:SELECT * FROM first_post; (1)

ZeroExistenZ (721849) | more than 8 years ago | (#15489844)

Wouldn't that rather be "SELECT TOP 1 FROM Posts WHERE sid=#06/06/07/194246#" ?

BN vs Amazon (3, Informative)

beavis88 (25983) | more than 8 years ago | (#15489546)

I know Amazon has software patents and all, but this (and just about every other book I see reviewed here) is ~20% cheaper at Amazon than it is at BN...

Re:BN vs Amazon (0, Flamebait)

larry bagina (561269) | more than 8 years ago | (#15489603)

slashdot gets a BN kickback. (must be a pretty big one, too).

Re:BN vs Amazon (1)

beavis88 (25983) | more than 8 years ago | (#15489680)

Yep, guess it's big enough that it outweighs the possible Amazon commissions lost to people like me that shop around :)

Re:BN vs Amazon (1, Informative)

CRCulver (715279) | more than 8 years ago | (#15489670)

The book is not only cheaper at Amazon [amazon.com] , but occasionally through the Third Party Sellers offering books there, one can get a mint book for pennies in comparison to the full price.

In any event, Amazon's patents shouldn't intimidate Free Software fans, as the GNU project ended their boycott [gnu.org] since there was no sign of danger.

Re:BN vs Amazon (1)

mcmonkey (96054) | more than 8 years ago | (#15490094)

Well, I did a search at Amazon for this book by ISBN and got this [amazon.com] .

I did the same search at B&N.com and got the page for this book. Can't buy what I can't find.

Re:BN vs Amazon (1)

CompiledMonkey (683393) | more than 8 years ago | (#15489713)

Amen to that. Amazon always has great deals when compared with everyone else.

Re:BN vs Amazon (2, Insightful)

fm6 (162816) | more than 8 years ago | (#15489718)

This isn't about software patents, or about prices. This is about who gives Slashdot the best deal for steering traffic to their site.

bookpool (4, Informative)

stoolpigeon (454276) | more than 8 years ago | (#15489725)

bookpool has it cheaper [bookpool.com] than amazon.

Re:bookpool (1)

MagicM (85041) | more than 8 years ago | (#15489972)

overstock has it cheaper [overstock.com] than bookpool.

Cheaper isn't everything (5, Insightful)

PCM2 (4486) | more than 8 years ago | (#15489885)

In fact, if you have access to a local, independently-owned bookseller in your area, you should be buying your books there instead of online.

Stacey's Books [staceys.com] in San Francisco doesn't give me Amazon's 34 percent discount -- in fact, it gives me 10 percent -- but it is a wonderful resource and not one I'd like to see disappear.

That's not hyperbole either. This year we've seen two classic, quality Bay Area bookstores close their doors: Cody's on Telegraph Avenue in Berkeley and A Clean, Well-Lighted Place for Books on Van Ness in San Francisco. These were not holes in the wall; they were spacious, carried a lot of stock and had served their communities well for years. (And believe me, the Bay Area in general buys a lot of books.)

The reality is that the book market is changing. Superstores like Borders and Barnes and Noble have a lot to do with it, and so does Amazon. Another factor is the overall decline in book sales to the American public. People walk into Borders to buy DVDs of Friends and they pick up a paperback of Harry Potter at the same time. That's not the model I want my booksellers to be based around; I want to support local businesses that understand their communities and are dedicated to selling books.

This is not to knock Amazon, or Borders or B&N for that matter; in communities where those are the only option, it's better to have someplace to buy books than no place at all. I still buy plenty of stuff at Amazon. But for books, I vote with my wallet.

Re:Cheaper isn't everything (1)

ars (79600) | more than 8 years ago | (#15490015)

In fact, if you have access to a local, independently-owned bookseller in your area, you should be buying your books there instead of online.

Stacey's Books in San Francisco doesn't give me Amazon's 34 percent discount -- in fact, it gives me 10 percent -- but it is a wonderful resource and not one I'd like to see disappear.


How about if people buy their books online, or where ever, and then send Stacey's Books some charity?

Personally I don't see how that's different.

The concept of buying someplace with a higher price to "support them" (as opposed to some other benefit, like service or selection) is no different then charity, so why not just skip the buying step and send the charity directly?

Re:Cheaper isn't everything (1)

PCM2 (4486) | more than 8 years ago | (#15490057)

The concept of buying someplace with a higher price to "support them" (as opposed to some other benefit, like service or selection) is no different then charity, so why not just skip the buying step and send the charity directly?

Obviously the reason I want to support them is because of their service and selection, not to mention the fact that they have a physical presence that caters to my community, which chain superstores can't do. Please, you're not that stupid.

Re:Cheaper isn't everything (1)

ars (79600) | more than 8 years ago | (#15490149)

And you missed my point.

For this particular book, why do you need to purchase from them? You know what the book is, so no service needed, and selection is also not aplicable.

So how is buying this book from them (which is what you recomended) any different then charity?

Re:Cheaper isn't everything (2, Insightful)

nschubach (922175) | more than 8 years ago | (#15490160)

But the small chain stores could never carry the inventory to be able to go in and pick up any book in publish. Amazon allows this (even if they have to order it) It's not going to take any longer to get to you.

As far as the "local shop" mentality. Why support a company that doesn't innovate? In the case of Amazon, it took very little to start them up. Even companies like UPS will offer dropship and warehousing services for the small business if they wanted to get into internet sales. If they choose not to go that route, I don't see why we as consumers should have to pay more for their lack of foresight/expansion.

Re:Cheaper isn't everything (0)

Anonymous Coward | more than 8 years ago | (#15490289)

I've established a bookstore in your area, please buy all of your books online and send me $1 charity for each purchase. You can rest assured that the $1 will go towards keeping this business local.

My address is.....

Useless to all but theoraticians (0, Flamebait)

MBraynard (653724) | more than 8 years ago | (#15489548)

The authors almost never mention particular database products.

SQL is implemented differently in all of the environments I have encountered it (yeah, I'm not a PRO, just a hacker, so don't hate on me.) Those environments are MS SQL, MySQL, FoxPro, and MS Access. I think I messed around with PostgreSQL. Maybe a few others.

Point is nothing is really transferable and even basic syntax varies widely as do optimizations and 'the best way to do x'.

It's great to see a book that tells me SQL can do pretty much anything - but I pretty much already knew that.

This book might be good for THEORY, but for actually getting useful and applicable information, the review leaves me wondering who would be a worthwhile reader.

Re:Useless to all but theoraticians (4, Insightful)

stoolpigeon (454276) | more than 8 years ago | (#15489690)

There are differences on the different platforms, but there is a standard and standard syntax ought to work in any rdbms. When it doesn't (access is the first example that comes to mind) that is a sign that what you are working with is not as good a system as it should be. One of the things I really like about postgres is that it is very standards compliant.
 
There is a transact sql book that I use frequently on multiple database systems. A small amount doesn't carry over, due to syntax differences. But the ideas on how to deal with sets of information in sql carry over. It appears that this book does that intentionally. And it should be useful in a very practical way if it is at all like the description.

Re:Useless to all but theoraticians (5, Insightful)

truthsearch (249536) | more than 8 years ago | (#15490033)

I disagree, but only to a small extent. I have extensive experience with MS SQL, Oracle, and mySQL. The basics of retrieving information are the same across all, but change very much when working on large systems. Select queries have to be written very differently on each system when tables get huge. For example, Oracle scripts with cursors are often much faster then regular joins if you know your data well. Yet on MS SQL cursors are the slowest way to go. On mySQL using temp tables in memory often outperforms outer joins, but not in the same cases as MS SQL.

When working in the extremes the strengths and weaknesses of each system have to be considered.

Re:Useless to all but theoraticians (1)

stoolpigeon (454276) | more than 8 years ago | (#15490098)

that makes sense. and i think there is a lot of value in becoming an expert on an rdbms. but think of the vast majority of databases, and the people working on them. i haven't run into many that weren't junk. in fact i'd be willing to wager, if there were ever a way to prove or disprove the assertion, that the vast majority of databases in existence are access databases made by people with no education in relational theory and the tables look just like spreadsheets.
 
i just started a new job this week and i'll be working as a dba on a very large system running oracle. i'm really looking forward to it. it is a huge step up for me and i have a lot to learn. but i have no doubt that i'll also be putting in time on the side on much smaller projects and doing my best to explain to people why i have these 'crazy' rules about how to design a database or how best to get information out of it. many of these people will be developers-- i have no doubt of that.

Spoken like a hacker, rather than a pro (4, Insightful)

PCM2 (4486) | more than 8 years ago | (#15489715)

It's great to see a book that tells me SQL can do pretty much anything - but I pretty much already knew that. This book might be good for THEORY, but for actually getting useful and applicable information, the review leaves me wondering who would be a worthwhile reader.

And yet, if you get out and talk to some of the real-world database consultants who get called in to clean up other people's messes, one of the complaints you hear again and again is that too many so-called DBAs learned their trade on a specific product, rather than understanding why databases work the way they do.

Optimizations that you introduce into your applications to cater to specific products' features (or work around their shortcomings) may be a fact of life, but they make for poor design choices. You should know what you're doing first -- which means a good understanding of database theory -- and layer all that syntactic hot-rod stuff on later.

Re:Useless to all but theoraticians (5, Insightful)

kfg (145172) | more than 8 years ago | (#15489721)

. . .the review leaves me wondering who would be a worthwhile reader.

Software engineers and Database Administrators.

An intuitive "hackers" understanding of physics is perfectly sufficient to construct a gocart out of 2x4s and baby coach wheels, but automotive engineers find that a knowledge of "theory" is rather useful in getting practical work done.

In fact if your software does not have a solid grounding in theory it may well be worse than useless, as software is nothing more than applied science. The computer is a mathematics engine. Nothing less, nothing more.

If you do not understand the underlying structure of your high level language and the low level mathmatical theory below that you liable to make grevious mistakes in first selecting your high level tools, then in the specific models that you impliment with your code and then in your code itself.

And be utterly clueless that you have done so.

KFG

Re:Useless to all but theoraticians (1)

MBraynard (653724) | more than 8 years ago | (#15490243)

I do have a degree in MIS, so all of the relational stuff (3rd normal form, etc.) is old hat to me - but I didn't NEED to go to school to learn this and it's relatively obvious to anyone who does it for a while of what works best. Very self-evident.

You don't need a whole book for this - you need a magazine article. A whole book on theory is much less useful than maybe a book with a chapter on theory and a whole lot of chapters on practical appications specific to a given engine.

The problem is that the differences in the engines reach SO DEEP and affect so much that you actually could have a book on theory - for each one of them.

Theory not a dirty word (4, Insightful)

fm6 (162816) | more than 8 years ago | (#15489838)

This book might be good for THEORY, but for actually getting useful and applicable information, the review leaves me wondering who would be a worthwhile reader.
SQL theory is useful and applicable. It's just not complete: you also need the specifics of whatever SQL implementation you're using. For that you need to go to books about the specific RDBMS you're using. You can't expect a general SQL book to cover every implementation of the language, any more than you expect Stroustrop [att.com] to tell you how to work with Visual C++.

Not every programmer needs to be a computer scientist, but they do need to learn a little theory now and then. That's especially true when you're work with relational databases, which are full of weird abstractions and subtle performance issues. Not having looked at this particular book, I can't say whether its overkill for what most SQL people do. I can say that most database hackers don't seem to know as much theory as they should.

Re:Useless to all but theoraticians (1)

mcmonkey (96054) | more than 8 years ago | (#15489910)

This book might be good for THEORY, but for actually getting useful and applicable information, the review leaves me wondering who would be a worthwhile reader.

I guess you skipped all the threads about computer science vs. programming and uni degrees vs a tech certificate.

Specifically regarding 'the best way to do x,' that may depend to a certain extent on the specifics of the platform at hand, but why do x? What do you hope to achieve? What are the desired results? Why not do y? If your thinking hasn't progressed past "basic syntax" you're not a hacker, you're a button pusher. Bang on your keyboard, you might as well be pounding rocks into gravel.

This book might be good for THEORY, but for actually getting useful and applicable information...

What do you think "useful and applicable information" is?? Think about driving a car. (*ducks* Yeah, the car analogies are played out.) The specifics of each make and model--the dashboard layouts, placement of controls--are your "basic syntax." These details are not the things you really need to know in order to learn how to drive. The THEORY of driving--concepts of acceleration, braking, steering--are the things you need to know BEFORE you can make proper use of the "basic syntax."

The reader for whom this book would be a worthwhile read is the person with an understanding that theory IS useful and applicable information.

WTF is a "theoraticians" (2, Interesting)

mcmonkey (96054) | more than 8 years ago | (#15490029)

And who modded that comment Insightful? Come on folks, it's garbage.
Point is nothing is really transferable
So they seasoned pro with 15-years relational database experience who hasn't worked with new SQL-X is just as good as someone with no db experience on any platform? And when SQL-X 2.0 comes out, all those so-called experts, with their knowledge of SQL-X 1.9 are going to be useless, right? After all, "nothing is really transferable."

EVERYTHING is transferable. That is, everything you've actually learned, everything you understand. If you're just mashing buttons, yeah, you might be a little lost when the buttons change. When telephones changed from rotary dial to push buttons, some people were still able to make calls. If course the basic syntax changed, and knuckle-draggers like the folks who modded the parent comment Insightful were SOL. But most folks who had some ideas about the THEORY of the telephone--that the little spinning disk on the phone didn't make the actual call but rather transferred information, and the buttons were just a new way of transferring the same information--adapted and moved on.

The fact that a computer even let such a concept be typed and communicated gives me hope for the day when machines rule the Earth, that they just might have enough of a sense of humor, or pity, to allow us humans to remain in their midst.

Re:Useless to all but theoraticians (1)

fupeg (653970) | more than 8 years ago | (#15490037)

SQL is implemented differently in all of the environments I have encountered

You confuse syntax vs. execution. Your statement is equivalent to saying that since C++ and PHP have different syntaxes, there is no point in studying algorithms or design patterns. Would you agree with this statement as well?

All relational databases rely on predicate calculus at the end of the day. Understanding how relations work is fundamental to understanding what happens when you write something like "select A.x, B.y from A.B where A.z=B.z" Similarly understanding things like b-trees and hashing functions will aid you in both schema design and query optimization. Understanding the theory helps you make the right kind of design. Your design may be implemented differently on different DBs, but simply having knoweldge of a particular DBs syntax will not help you make the right design choices.

Re:Useless to all but theoraticians (2, Insightful)

sqlgeek (168433) | more than 8 years ago | (#15490051)

If you're worried about syntax variations across databases, then this is clearly not the book for you. However, once you're past syntax you need a book like this -- and I haven't seen another like it. The author is talking about how SQL works. What's the implication of using a correlated-IN clause vs. a correlated-EXISTS clause? Regardless of the syntax of a particular SQL dialect it is crucial that you understand these sorts of things unless you want to stare at the db blindly and wonder why it's slow.

Re:Useless to all but theoraticians (2, Interesting)

grrrgrrr (945173) | more than 8 years ago | (#15490236)

For theory books I think you may do better with a book that has litle to do with sql. I find Database in Depth by C.J. Date a nice theory book

MOD UP if the new Slashdot HTML sucks (-1, Flamebait)

DrDitto (962751) | more than 8 years ago | (#15489556)

I'm burning karma, but really, the old HTML was much much better. Things are in the wrong spot including "Read More", and the rating of each message.

Re:MOD UP if the new Slashdot HTML sucks (0, Offtopic)

GmAz (916505) | more than 8 years ago | (#15489589)

Ya, its off topic, but you are right. This new slashdot is nice and all, but stuff needs to go where it belongs.

Re:MOD UP if the new Slashdot HTML sucks (1)

mobby_6kl (668092) | more than 8 years ago | (#15489597)

I can't mod you up because I don't have any mod points, but I agree that I preferred the old one.

To keep this at least somewhat on topic, the table with the book information seems to have 0 margins/padding [imageshack.us] , making it a little ugly/difficult to read.

Re:MOD UP if the new Slashdot HTML sucks (0)

Anonymous Coward | more than 8 years ago | (#15490023)

You'd think that they'd have tested that sort of thing.

Especially when it would have only taken one or two people a couple of work days at most to really go over it all and make sure that there were no glaring errors in the layout.

Working at Slashdot must be the most relazing experience in the world, what with all that not working that they do.

Re:MOD UP if the new Slashdot HTML sucks (0)

Anonymous Coward | more than 8 years ago | (#15490292)

the old HTML was much much better.

The HTML hasn't changed at all. It's the CSS that's changed.

art (4, Insightful)

Lord Ender (156273) | more than 8 years ago | (#15489570)

If you think SQL is an "art," you are a hack. Designing proper databases and the SQL to use them optimally falls under the domain of science/engineering. 95% of developers see relational databases simply as a means for a persistent data store, but that's not what it was designed to do. If you don't know engineering (what you do when designing functional systems*) from art (painting pictures, etc) you should have gone to a better college.

See this page [wikipedia.org] for a start on the science of databases.

*Yes, I know creativity is usually involved when designing things. That doesn't make it art.

Re:art (1, Insightful)

Anonymous Coward | more than 8 years ago | (#15489602)

You must be one miserable bastard to work with.

Re:art (2, Funny)

Mindwarp (15738) | more than 8 years ago | (#15489639)

A slashdotter who did not build his own computer is like a jedi who did not build his own lightsaber.

Imaginary?

Re:art (2, Insightful)

gowen (141411) | more than 8 years ago | (#15489672)

There's a difference between something being an art and something being art.

Science, yes even computer science, and mathematics are particularly susceptible to elegance, and science (and engineering) built on elegant designs, based on concrete principles, have fewer points of failure, and can often be conceptually simpler, and algorithmically faster. Art is simply the application of insight, and this book (seems) to show us how insight into the problem space and the mathematics can achieve elegant (and efficient) designs.

Having said that, I know nothing about SQL, a bit of database theory and a lot of set theory. Also, that book review was far above the usual /. standards, where book reviews look more like book reports. Here's to you, SQL-book-reviewing-guy.

Art is about creativity, not rote coding (5, Insightful)

Graboid (975267) | more than 8 years ago | (#15489704)

Ahhh - but the best scientists are artists as well. (In fact, scientists and mathematicians often have more in common with artists than engineers).

Sure, the mechanics of programming is rather dull and boring, but large scale system design often requires considerable creativity that is much better done by people not constrained by artificially perceived IT limitations.

Coding J2EE isn't an art, but designing/building a massive neural net or complex, distributed game/simulation is. MySpace, Google, eBay, etc weren't concieved by 'classic' engineers, but, rather, by creative people who understood how technology can enable new paradigms.

Re:Art is about creativity, not rote coding (4, Funny)

gowen (141411) | more than 8 years ago | (#15489717)

Ah. You were doing so well, and then you said "paradigm".

Re:Art is about creativity, not rote coding (2, Insightful)

tthomas48 (180798) | more than 8 years ago | (#15489770)

He used the word correctly. It is a real word, unlike "actionable". Just because a word has been overused in bizarre contexts, doesn't mean it can no longer be used in the correct one.

Re:art (0)

Anonymous Coward | more than 8 years ago | (#15489796)

I agree, art is an overused word.

It is strange that most people have no respect for those who choose to be artists (believing them to be losers), then try to label an analytical task (done using the other side of the brain) "artistic", in order to make it sound like a better accomplishment.

Since what is "art" is subjective, you can call SQL an art, but it carries little meaning.

Re:art (1)

Vellmont (569020) | more than 8 years ago | (#15489886)


Designing proper databases and the SQL to use them optimally falls under the domain of science/engineering.

The process of doing science isn't as clear cut as you're trying to make it out to be. You're thinking of science as the nice, clean end product that's been checked and written in textbooks. Getting those results can most certainly be an "art" (that is something learned by experience, and not easily definable). Working with something as complex as a database is similar in that the performance you get from different databases isn't always so easy to define. Databases are among the most complex pieces of software out there, so it should be no surprise that some people see working with them more art than science. There's really no call for calling anyone who sees the world differently than you do "a hack".

Re:art (1)

msuarezalvarez (667058) | more than 8 years ago | (#15490106)

Donald Knuth says in the foreword to the "A=B" book by Marko Petkovsek, Herbert Wilf and Doron Zeilberger (which is essentially the solution of Knuth's exercice 1.2.6.63!):

Science is what we understand well enough to explain to a computer. Art is everything else we do.

That's a high bar!

The Art of Computer Programming (1)

dazey (903451) | more than 8 years ago | (#15490016)

References to Knuth's volumes titled "The Art of Computer Programming" http://www-cs-faculty.stanford.edu/~uno/taocp.html [stanford.edu] are sprinkled liberally throughout many, many papers in computer science, especially wrt algorithms. It's more of an abstract art, as opposed to the "physical" arts like paintings and sculptures. You can't ignore the engineering aspect of it, yes, but if you manage to engineer a system well AND do so with simplicity, elegence, and creativity ... well, that distinguishes the true progessional.

Aristotle (0)

Anonymous Coward | more than 8 years ago | (#15490267)

According to Aristotle, arts have techniques, while sciences have laws.

Great Statement (3, Funny)

lbmouse (473316) | more than 8 years ago | (#15489587)

"for SQL there's a bigger gap between what the code says and what the code does"

I couldn't agree more. Sometimes while working in SQL I really wish I had a time machine [wikipedia.org] and a rubber hose.

Re:Great Statement (1)

msuarezalvarez (667058) | more than 8 years ago | (#15490081)

SQL is a declarative language, not a procedural one. It is in that aspect related to functcional and logic programming languages. SQL code describes what you want to get, not how to get it. That is the actual intent of the design.

Where's the news? (0, Offtopic)

Graboid (975267) | more than 8 years ago | (#15489588)

Book reviews seem so out of touch with the flow of the rest of Slashdot (except to the extent that everyone can comment about stuff they haven't read).

Could Slashdot not post book reviews to the main section?? At least not at the same level as a news story that locks Slashdot for an hour - maybe just a sentence "Art of SQL review" with a link then post a real news story as well.

The reviews are neither timely news nor really commentable (although that rarely stops us).

I quite like having the section and appreciate the time the authors put into these reviews (and have bought a couple because of that), but they shouldn't be mixed into the news postings.

Re:Where's the news? (3, Informative)

PCM2 (4486) | more than 8 years ago | (#15489759)

Could Slashdot not post book reviews to the main section??

I like book reviews.

Homepage preferences [slashdot.org] are your friends.

Bummer, trees (3, Insightful)

plopez (54068) | more than 8 years ago | (#15489595)

Chapter 7 discusses tree-structured data

Looks like no discussion of many-to-many relationships. This would make any book on databases and sql queries of limited value, not much more than a beginner book.

Trees are of limited value, they only exist in special circumstances. If you stick to tree structured data relations then you will almost always have to do wierd hacks that may threaten data integrity.

While many-to-many *seems* harder, as a data model M:M is often a much better practicle solution. As well as modeling the reality of the situation in a much more accurrate manner.

My $.02

Re:Bummer, trees (1)

stivi (534158) | more than 8 years ago | (#15489687)

Well, I have not read the book, but I think that by trees they mean hierarchical structures, usualy implemented in one table: id_employee | id_superior | employee_name | ...

Keyword for traversing such structure is CONNECT BY [adp-gmbh.ch] .

Re:Bummer, trees (1)

Bogtha (906264) | more than 8 years ago | (#15489757)

Trees are of limited value, they only exist in special circumstances.

Yes, in fact, I'm struggling to remember the last time I saw a tree structure, as I post one of many replies to your comment, which in turn is one reply of many to the article.

Trees crop up in all kinds of different places, and the approaches most newbies tend to take are awful. That warrants their inclusion in a book like this. I agree that many-to-many relationships are important, but that's no reason to neglect tree structures.

Re:Bummer, trees (1)

plopez (54068) | more than 8 years ago | (#15489841)

But are they a natural artifact of a conversation or because people just can't wrap there heads around a different structure becase that is all they were ever taught.

I for one am very frustrated with constant drilling down through file structures, conversation threads, posting comments which associate across different parent posts conceptualy but I have to post twice if the point is relevent to 2 source posts.

A cloud view based on meta data and linking would be nice. Almost like, date I say it, relationships between web pages? Why parent child? Why a heirarchy? No good reason, really.

We must free our minds from the slavery of trees... :)

Re:Bummer, trees (1)

Bogtha (906264) | more than 8 years ago | (#15489900)

But are they a natural artifact of a conversation or because people just can't wrap there heads around a different structure becase that is all they were ever taught.

I believe that they aren't a natural artifact of a conversation, but nobody has come up with a decent interface for multi-parent comments. There have been attempts, but they all end up being too confusing for very little gain. Comment trees are the optimum balance between complexity and usability.

easy (1)

BitterAndDrunk (799378) | more than 8 years ago | (#15490237)

Bills of Materials lend themselves perfectly well to tree structures.

Re:Bummer, trees (0)

Anonymous Coward | more than 8 years ago | (#15489858)

The problem with SQL is that anything beyond the insanely easy is obscenely complex. Which is why a whole bunch of simpletons are so religious about it and say stupid shit like the parent.

Re:Bummer, trees (2, Informative)

eh2o (471262) | more than 8 years ago | (#15489869)

FYI this book does mention many-to-many relations a few times, including its implications for multiple indexing and in the chapter on trees (since graphs are a generalization of trees where a node may have multiple parents). In the book there are 4 different data structures proposed for trees.

Re:Bummer, trees (2, Informative)

sqlgeek (168433) | more than 8 years ago | (#15489989)

Didn't look at the sample chapter, did you? It deals with a many-many relation several times in varying contexts.

Trees are graphs; M2M is a general graph structure (1)

jabbo (860) | more than 8 years ago | (#15490283)

Storing things as adjacency lists (which, obviously, is an M2M table where the node properties live in their own normalized table) tends to be faster in the long run for all but the largest and most active trees.

Nested sets are cool, and I've implemented them (in MySQL 4.1 no less), but at the end of the day, traversing a graph happens far more often and more usefully.

This seems to be where the CS majors separate from the rest of the crowd. Point out that they ought to know how to do this unless they failed 2nd year ;-)

One year of SQL is significant experience? (3, Insightful)

Osty (16825) | more than 8 years ago | (#15489635)

Perhaps that's what's wrong with database development these days (just check out The Daily WTF [thedailywtf.com] , as it seems they have a SQL example every other day). When a single year of experience is considered "significant" and "experienced", it's no wonder there are so many crap DBAs out there. We look for people with 5+ years of C# experience (ha! Good luck finding someone with more than 5 years experience ...) for intermediate-level developer positions. There's no way someone with only a year of SQL experience would qualify for an intermediate-level DBA position.

Just as background, I've been doing development on SQL Server for 6 years now (from SQL 7 to SQL 2005). I'm still learning, still finding ways to improve my code's cleanliness and performance, still finding new things I can do in SQL. For example, SQL 2005 finally has CTEs, making it only the second database to implement that ANSI SQL99 standard. CTEs make it very easy to do things that were painfully hard before, like walking a tree or implementing a recursive algorithm over sets of data.

After my fourth year of working with SQL, I'd have been willing to say I had "significant" experience with SQL. Four years is arbitrary -- it really depends on how much you work with it day to day. Someone may have "significant" experience after only two years, while someone else may not be significantly experienced until he's worked with SQL for eight years. If you had to put a number of years on what would constitute significant experience, I'd err on the safe side and go with three or four years. Certainly not just one year.

Re:One year of SQL is significant experience? (1)

plopez (54068) | more than 8 years ago | (#15489740)

In most areas, 3-5 years is the minimum.

This goes for trades as well as engineering. The EIT paradigm used in engineering requires logging hours under a licensed engineer for what amounts to a 3 r more year apprenticeship.
Most trades programs do not allow you to be called 'Master' until after apprenticeship and being a journeyman for a few years.

The upshot being that most plumbers are probably better trained than IT people.

And the posts on this board prove it. Also, as bad as the review was, it gave me enough information to *not* buy the book (hint: I never buy books that mention Celko in a positive way and I never buy books that are married to the concept of heirarchical data). The authors sound too much like SQL monkeys to me.

Re:One year of SQL is significant experience? (1)

truthsearch (249536) | more than 8 years ago | (#15490137)

FWIW, I have 10 years of experience with Oracle and MS SQL and I still don't consider myself an expert. I wrote reporting queries against one of the largest Oracle databases in the US and our truely expert DBAs were always teaching me something new.

Some people talk to me about databases like I'm Yoda. But I label myself as "very experienced." When performing the right kind of work I'd say it takes at least 4 or 5 years to gain significant experience.

Developers and SQL (5, Insightful)

DebianDog (472284) | more than 8 years ago | (#15489641)

As a DBA, if developers would read... oh.... I dunno... just Chapter 1... the basics of SQL... of this book... any SQL book really AND understand "the basics"... My job would be 100 times easier!

I spend much of my time explaining why a 5 page SQL statement "that takes a long time" is NOT A DATABASE PROBLEM!
/rant

Re:Developers and SQL (1)

cpt_rhetoric (740663) | more than 8 years ago | (#15489765)

ROFL. I remember see code once in MS SQL, where this developer opened a cursor on a table to find the row that had a particular value he wanted, he would then take the id for the row and then basically select from the very same table where the id for that row was the id he got from step #1. Typically though, this type of coding came from ABAP developers who suddenly found themselves coding in a non SAP environment.

Re:Developers and SQL (1)

NoOneInParticular (221808) | more than 8 years ago | (#15489768)

Why is it not a database problem? Wasn't the whole point of SQL that you could state the result you wanted in a declarative manner and let the database figure out how to get you your result fastest? If it can't, why the hell do we need to write SQL, as I do now how to traverse an indexed btree fast using a simple loop or recursive algorithm? What's that layer doing there apart from being a pain in the neck?

Re:Developers and SQL (2, Informative)

Fulcrum of Evil (560260) | more than 8 years ago | (#15490159)

Why is it not a database problem?

Because it's a 5 page SQL query.

...how to get you your result fastest?

Sometimes, fastest still takes a long time.

Re:Developers and SQL (2, Interesting)

Pfhreakaz0id (82141) | more than 8 years ago | (#15490035)

and as a developer, I will counter, that, in my experience, the reason there was a 5-page sql query in the first place was because the DBA had very restrictive rules about normalization (not realizing that denormalization is a common, industry-standard way to improve database performance). Why did my query (this was at my last job, which had the dba's from hell) have 16 joins in it? Because I had to split stuff up across 6 tables that I knew I would always be accessing at the same time anyway...

SQL fun (0)

Anonymous Coward | more than 8 years ago | (#15489669)

One difference between SQL and a conventional procedural programming language is that for SQL there's a bigger gap between what the code says and what the code does.

That's kinda the point. Since data management is based on a complete theory, it's possible to write what you want *declaratively*, and let the DBMS figure out how to do it. You might be familiar with another declarative mini-language: arithmetic. For example, you write "1+2*foo", knowing that the computer will figure out how to compute that and (conceptually) replace it with a result value. SQL should be the same way (but of course they fucked it up and ends up being half-procedural, half-algebraic, guaranteeing that both the people who understand databases and the people who don't will be equally confused).

The first few chapters of the book lay a foundation for the rest.

Get a book on relational theory (I recommend Database In Depth, only 250 pages). Then you will have a *real* foundation.

The phrase "A clever optimizer ... will be able to" is too hypothetical by half. Is this an existing hypothetical query optimizer, or a vision of a future optimizer?

There's no "existing hypothetical" query optimizer. That doesn't even make sense. But the point is, this shouldn't be the first concern when formulating database queries. In theory, you should be able to write any equivalent query and have it run at the same speed, so start with that in mind and then optimize when needed.

because he's not much interested in telling you what actually happens when a particular SQL statement is executed by a particular database

No shit, if you're trying to understand data management, don't waste time thinking about PRODUCTS. Products come and go, data management theory won't change unless the universe does. Would you expect a book on calculus to talk about which form of integral is faster to computer? That comes AFTER you master the fundamentals.

Start with a good book on theory, figure out how to translate simple, concise relational algebra queries into SQL (and wince), then figure out how to make them go faster. As an added bonus, you'll also understand object (network) and XML (hierarchical) models (such as they are), since they are just subsets of the relational model.

A useful review - Thanks! (2, Informative)

Anonymous Coward | more than 8 years ago | (#15489675)

Many so-called book reviews on Slashdot fail to review the book. Instead, they simply state what each chapter covers. This review is actually useful. It describes the book's target audience, gives a sense of what the book does and doesn't contain, and helps me understand whether the book would be useful to me. Thanks!

SQL says what to do (5, Insightful)

booch (4157) | more than 8 years ago | (#15489695)

there's a bigger gap between what the code says and what the code does

That's stated incorrectly. With SQL, the code says what to do, but it does not say how to do it. That's the difference between "normal" procedural code and languages like SQL.

Re:SQL says what to do (1)

Municipa (99320) | more than 8 years ago | (#15489772)

I don't think that is what he means. I think what he means is that it takes more thought about the code to understand exactly what it will do compared to the size of the code.

Re:SQL says what to do (1)

booch (4157) | more than 8 years ago | (#15490128)

To me, that's generally a good thing. The alternative is to write a whole bunch of code to do one simple thing. One thing I remember about using Lisp is that the amount of concept per line was huge. Maybe you have to think about each line longer, but each line accomplishes a lot more. Generally, that trade-off is in favor of languages like Lisp -- at least for highly competent programmers.

Re:SQL says what to do (1)

NoOneInParticular (221808) | more than 8 years ago | (#15489813)

And like with any declarative language, saying what to do is followed by wiggling chicken bones over the database cache and indexing at random places to actually get it do to what you said it should do within your lifetime. Or you can buy this book and figure out the subtleties of finding out how to say what you want with sufficient hints to how you want to get it done for the dumb machine not to choke on it. What was again the advantage of a declarative language?

SQL Books (3, Insightful)

Municipa (99320) | more than 8 years ago | (#15489707)

Pretty much every book on SQL I've seen only gives you obvious examples and covers the most simple uses. Every project I've worked on (for about 10 years) where there is pre-existing SQL written, almost all of it is written inefficiently. I'm not sure this book explains this kind of thing. But I've found 99%+ of the time you don't need to use a cursor, and it's almost always slower.

SQL can do a lot more than most programmers ever try to do with it. There are a lot of clever tricks you can use exploiting its set based nature. The only place I've seen clever solutions beyond simple insert/delete/update statements is some of the trade magazines; the one for MS SQL Server sometimes has some very neat examples. These trade magazines have examples and ideas presented using the SQL language of a particular database, but it's almost always portable wihtout much work. I consider myself pretty good at SQL and even I find it's hard to learn more to get to the point where I can design clever SQL more frequently. Anyone else find that too?

Another thing I've noticed is on some open source projects (and perhaps some closed source ones), particularly web based ones, there is displayed at the bottom the number of database queries used to generate the page. They are often 10 or more, which almost always seems ridiculous. I think there just aren't all that many people out there who understands what SQL can do, how it's different than procedural languages and how to use it beyond a simplistic straight forward approach. Hopefully this book helps explain that - I'll probably browse a bit the next time I'm in a book store.

Opening line (1)

skiflyer (716312) | more than 8 years ago | (#15489709)

One difference between SQL and a conventional procedural programming language is that for SQL there's a bigger gap between what the code says and what the code does.

What? My SQL code tends to do exactly what the code says it will, are you trying to say that it's a high level language or am I missing something here?

Sounds interesting, but ... (1)

tomhudson (43916) | more than 8 years ago | (#15489710)

... trying to read the sample chapter screws up the tab holding that page in firefox (1.5.0.4) - scrolling no longer works for that tab until you either close it or go to another url, etc. It's too bad, it sounds like a good read.

This is an excellent book (2, Informative)

tcopeland (32225) | more than 8 years ago | (#15489720)

I'm slowly working my way through it; it's a great book on a number of levels. The writing itself is very nice, with a real personality showing through and not just the usual dry technical flavor. The illustrations are done in a nifty "drawing" style that looks good and portrays the data well. The technical insights are very helpful; after reading what I've moved through so far I've rewritten some of my Rails code [blogs.com] to be more efficient.

I highly recommend this book; the $40 you'll spend on it will be repaid the first time you delete a swath of Java looping code and replace it with an additional subquery. If I can do half as well on my next book [generating...javacc.com] I'll consider it a job well done.

sql vs. procedural (2, Interesting)

JCOTTON (775912) | more than 8 years ago | (#15489816)

Now that the subject has been raised, my 2 cents.
I have found (and who can disagree (just trolling)) that at least half of the production databases that I have come across hare not normalized. Go figgure.

Anyway, this being the case, I have found that SQL is poor in handling a non-normalized table/database. (cant really call a non-normalized table as a database can we? (nuther troll))

For example. We keep a complete record for each person for each pay period. Even inactives.

I am asked to give a list of all active employees for a date range, and a lot of payroll detail, personal detail, etc. Guess what? Simple SQL gives a lot of duplicate names. I wish that there was a simple way filter. (Yes, I can do this in sql, but my point is that it is not handled natively in sql. I would like a simple command - give me all names and all their data for the latest pay period - something like that.

All procedural languages will handle this problem nicely.

metaphors be with you

Re:sql vs. procedural (0)

Anonymous Coward | more than 8 years ago | (#15489970)

select distinct

select distinct (1)

mveloso (325617) | more than 8 years ago | (#15490274)



Actually, they don't, in the sense that there is no one single built-in command to handle this case. Just like in SQL, you (or someone else) has to write the function that performs a 'select distinct' equivalent.

Unless you're using a targeted-product (one built specifically for your data needs), nothing you do will be handled natively in any language. You can build this functionality by using correct SQL or writing the appropriate functions in a procedural language.

And why don't you consider 'select distinct' a built-in function?

"Art of SQL" Cheapest a Buy.com (1)

roblambert (230731) | more than 8 years ago | (#15489867)

You can get "Art of SQL" cheapest at Buy.com, see:


Lowest Prices for 'Art of SQL'

an art? (1)

SekShunAte (978632) | more than 8 years ago | (#15489876)

hmmmm...let's test that:

SELECT Creativity.Passion, Creativity.Insightfulness, Ability.Palette, Ability.Colorscheme FROM Creativity INNER JOIN Ability ON Creativity.AbilityID = Ability.AbilityID WHERE Creativity.Passion = "Mediocre";

Result Set:
Creativity.Passion | Creativity.Insightfulness | Ability.Palette | Ability.Colorscheme
Mediocre | Dreamer | Basic | Shit Brown

I have way too much time on my hands.

procedural programming (4, Insightful)

jbgreer (4245) | more than 8 years ago | (#15489925)

"One difference between SQL and a conventional procedural programming language is that for SQL there's a bigger gap between what the code says and what the code does."

Well, certainly one difference between SQL and a conventional procedural programming language is that SQL isn't procedural, it's declarative. One describes the data a query such produce, rather than state a set of steps necessary to achieve a desired result.

jbgreer

Sun Tzu! (1)

fm6 (162816) | more than 8 years ago | (#15489952)

The reviewer managed to miss something that's pretty important: the authors are totally infatuated with Sun Tzu's The Art of War, even to the point of copying that book's chapter titles [wikipedia.org] . Which is evidence either that they're educated people building on age-old wisdom — or they're half-educated dweebs copying a book that's faddish right now.

Difference (1)

Brownstar (139242) | more than 8 years ago | (#15489978)

One difference between SQL and a conventional procedural programming language is that for SQL there's a bigger gap between what the code says and what the code does

Or more importantly SQL is not a procedural programming language at all. Please don't try to compare the two together at all, it just leads to misconceptions about what SQL is and how it works.

the sample chapter is promising (2, Informative)

sqlgeek (168433) | more than 8 years ago | (#15489979)

I like the look of this book quite a bit, judging soley from the sample chapter. It talks in a straight-forward manner about the factors that determine how a database goes about it's job and how you can make that job easier or harder. If the rest of the book plays out similarly then thorough understanding of this book as well as Tom Kyte's would make for a programmer I'd love to hire.
Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Create a Slashdot Account

Loading...