Slashdot Mirror
SQL Hacks
Scott Walters writes "Many of the recipes in SQL Hacks
will improve the SQL you write day to day, and
many will give you the confidence to attempt much more involved tasks with SQL.
Other recipes will rarely if ever be needed, but make for a entertaining and
education reading in a similar way that "worse case survival scenario" books do — SQL is pitted against the most difficult analysis tasks just as survival scenario
books pit humans against pavement and lions.
SQL Hacks fits well in the Hacks series, which raises the bar on advanced books by offering
large, eclectic sets of tricks for problems that an unambitious person (a non-hacker)
wouldn't ever push technology hard enough to run into.
Put another way, the questions answered in a good Hacks book are ones that would get a
"good question" comment rather than a an "RTFM!" response.
It does a good job continuing where O'Reilly's SQL Cookbook left off, which is always
difficult with two books written at slightly different times by different authors.
Still, it's harder to review a Hacks book than a Learning book as, with hacks, the
sky is the limit, and the reader will always find herself wishing for more.
To this end, I hope O'Reilly continues to publish newer editions of their various
Hacks books, drawing in more and more content in each edition, and identifying recipes
that might better serve in the Cookbook counterpart." Read the rest of Scott's review.
SQL Hacks
author
Andrew Cumming & Gordon Russell
pages
386
publisher
O'Reilly & Associates
rating
7
reviewer
Scott Walters
ISBN
0-596-52799-3
summary
Tips & Tools for Digging into Your Data
SQL Hacks skips most of the tutelage and shows you very specific ways for doing specific chores, with more explanation of how to adapt it than theory behind it. Most hacks have database specific information for the five databases the book tackles, and many hacks are inherently different on each system, making them completely different solutions to the same problem. Those five databases are Microsoft Access, Microsoft SQL Server, MySQL, Oracle, and PostgresSQL; most of the ideas require work to adapt or are completely specific to the database system, so I wouldn't suggest straying from this supported set. The authors did their homework, and SQL Hack's strengths are the depth, detail, and level of knowledge with which each database system is covered, and the book's willingness to get down and gritty. There's never an impression that juicy details were omitted because the authors didn't want to expend the effort to pick a colleague's brain or hunt down a factoid that never got documented elsewhere. Learning how to create indices on functions with multiple arguments in Postgres was worth more than the "hack" it was a footnote in. This dedication carriers over to screen shots showing how something is done in Microsoft Access directly opposite Unix shell pipelines between grep, perl, and the SQL command shell. Most books, including mine, are a bit awkward or vague on either Unix or Microsoft Windows, but the author's and contributor's experience on this one expertly covered platforms specific database topics. Besides just database systems and platforms, the authors challenged themselves to show how to securely and efficiently use the database interfaces of a set of languages: C#, Java, Perl, Python, and PHP. The polish shows, and you'll have absolute confidence that all of the tricks really are at your fingertips, regardless of your choice of operating system, database system, or programming language.
It gets bonus points for mentioning non-obvious types of input, such as cookies, that must be sanitized or sent through bound parameters, in its discussion of SQL injections. In the security department, it looks at SQL injections from three points of view: early on in the book, correct code is shown; later, SQL injections are shown from the point of view of the attacker, with several pages of strategies and scenarios for formulating attacks; and then from the point of view of the defender, who has to defang and avoid these scenarios — extra bonus points for this comprehensive treatment.
If you're looking for a quick buy/don't buy indication, then, by all means, buy it. That is, assuming that it's not intended to be your first or only SQL book. By it's own indication, it won't teach you the basics of database normalization, installation, and so forth. I would buy it as a second SQL book, though, after the fantastic 'The Practical SQL Handbook', as it's written to a much higher standard than most books, and gets things right, such as security, the intricacies of using a database to handle accounts, and transactions and shopping carts. The cover text promises lots of advanced hackery, but that's vague. "Pushing the limits of SQL"... "Solve puzzles using SQL"... "Manage users and audit the changes they make to the database".
Here are the major sections: SQL Fundamental; Joins, Unions, and Views; Text Handling; Date Handling; Number Crunching; Online Applications; Organizing Data; Storing Small Amounts of Data; Locking and Performance; Reporting; Users and Administration; and Wider Access.
Wider Access requires some explanation. It deals with locking down the various database systems to securely providing guest accounts, or, more generally, to limit damage in the case of an SQL injection attack or similar compromise.
With some well designed tables, SQL Hacks will show you quite a few tricks, some of them quote involved, quite non-obvious, and quite clever, to extract meaning from the data. You'll probably learn quite a few new types of reports you can do — intersecting ranges from different sets of data, outputting SVG pie charts, swapping rows and columns, finding medians, computing running totals, and computing running functions such as compound interest struck me as the most useful and got mental bookmarks.
I have two metrics for this book. The first metric is whether I'd buy it if I came across it in a book store, and that's a function of whether I'd have exhausted what it had to offer after an hour or so of furious skimming and intentionally picking out the best parts from the table of contents. Very few books make this cut for me.
The other metric is whether the authors did at least what I imagine I would have done were I writing it. This test is also a difficult one but builds in a great deal of forgiveness as my ideas are quite likely dumb ones.
I totally dig the cut-and-paste ASCII query results. The authors could have easily marked all of those up in DocBook and made it prettier but also alien compared to what you'll see at the computer. They're not ashamed of the SQL command shell, and they're not ashamed of SQL.
Many hacks have several examples, covering the problem with different constraints and end goals in mind.
Multi-platform, and thoroughly so. One moment, it's showing how to use XSLT tools from the command line on Microsoft Windows, and on the next page, there's a Unix shell pipeline with wget, xsltproc, and grep. Perl one-liners abound, and there are screen shots from Windows applications with instructions for navigating the menus and setting the needed options. You won't feel shortchanged for running the "wrong" platform.
When a powerful, modern SQL extension, such as replace, gets ratified by the standards committees, the authors let you know. Sidebars are spread around sharing the good news that sometime you might not have heard of before is portable. At the same time, some features are just fluff, and you're warned off of operations intentionally left out of the SQL92 standard.
Sometimes database systems have non-portable local extensions, such as MySQL's full-text indexing and SQLServer's XML handling features, and lots of these get motioned too, usually as variations on examples demonstrating the feature as a short-cut or simplification.
The treatment of security is first rate. The polish is top notch. Writing a book is a huge undertaking, and the economics of book publishing gives publishers little margin for advances. A book that reads like it's third release but is actually in its first can only be the product of an exceptional level of dedication by the authors.
Rarely, the authors do get tutorial-ish, but only a little, and I think it works: "Choose the right join style for your relationship" deals the difference between inner and outer joins, and whether records should be partially populated with nulls or omitted entirely when relations between tables can't be made for a record. Another section shows how to convert between subqueries and outer joins, and talks about when it's possible, and this serves as a sort of lesson in demonstrating the equivalencies between the two.
The "Hacks" format is similar to the "Cookbook" format. Both offer small, randomly-accessible (flip to it when you need it) examples of how to accomplish various tasks. In the traditional, MIT circles, a hack is piece of work that's either brilliant in its simple elegance or else brilliant in its expediency and simple effectiveness, and as such, is worthy of some esteem. It's also work that's custom for a particular scenario and has limited domain — in other words, it's a highly specialized fix or improvement. If a stock fix is applied systematically, that's mechanical, not clever. By this definition, showing users how to invoke their SQL monitor, or showing users how to decide whether to use an outer or inner join, are not hacks. Few of the recipes triggered this peeve, and they were early in the book, but including those few muddles the question of who the audience is, and lowers the standard for the Hacks series, endangering its basic premise. 'SQL Hacks' isn't alone in this sin; most of the Hacks books do it to some degree.
It was written by two professors at Napier University in Edinburgh, Scotland. The style, grammar, and presentation are perfectly fine — but only that. It's not a bone dry college text book, but it was written with a dedication to professionalism that can make a technical book tedious and will certainly keep it from becoming a classic. The literary power of Brooks, Hoare, or Wall is conspicuously absent.
Authors of Hacks books are at liberty to tap the experiences of the best and brightest of the field, and the best and brightest often have tricks just too strange, clever, or specialized to fit into any ordinary sort of text. I'd like to imagine that if I were charged with writing one of these, I'd have hundreds of contributors (I'm not likable, but I am persistent). Nothing against the contributors (two of them more than 20 years experience each), but why stop at three?
I said I had two benchmarks: whether I'd be likely to walk out of a bookstore with it if I had an hour alone with it to try to get my fill, and whether it touched on the subject that I thought it should.
Before cracking the cover, I stopped to ponder what would really impress me, and what I'd like to see. The Internal Functional Programming Competition had a puzzle solved by the contest winner using SQL. I'd like to see similar combinatronics and optimization problems solved using SQL. I'd like to see a good implementations of semi-infinite-strings, the text indexing data structure and algorithm that Google uses. I've done a version of this, but my implementation leaves something wanting. When reforming badly non-normalized databases, I've had to build a normalized database in parallel and populate it from queries on the non-normalized one. It would be interesting to hear how other people approach that problem, and what I can learn from them. There are other jobs that I've tackled and managed despite never having been prepared for. Renumber a display_order priority on records in response to the user adjusting or reassigning priorities. Trees using self-joining tables is something more people should be exposed to, especially when presented with non-normalized data.
There was no semi-infinite-string implementation, but the book showed how to build full-text indexes the optimal way for each database, using built-in full-text indices and optional add-on modules offering full-text indexing. The renumbering example took the more general form of running-totals computations. There were a few examples of self-joining data, and one tree example visualized the structure. Normalizing data had tricks, including some with views, and it showed how to use Cartesian joins to do combinatronics problems. So, aside form one sort-of, the authors nailed my entire wish list. That's amazing — I've never had that happen before, actually.
The highest endorsement a book can earn from me (a cheapskate, who already has a good deal of knowledge from working the industry for ten years) is getting bought on a random trip to the bookstore where I hadn't been looking for or intending to buy anything, and paying full price on top of that. Books that are surprising, riveting, and so packed with information that I couldn't possibly copy all of the best parts down and exhaust it in an hour or two are the ones that get purchased in this manner. I have 'SQL Hacks' in my hot little hands here at home, so this benchmark is now synthetic, but... I'm somewhat undecided, and not sure whether I would or wouldn't walk out with it. More likely, I'd just put it on my wishlist and pick it up later, for a discount (I'm a cheapskate, remember). If you don't know how to do more than half of the things listed in the table of contents, most certainly buy it. If you find yourself frequently working with SQL and constantly face new problems, buy it. If you find yourself still learning SQL and wanting a variety of examples, buy it. If you're shopping for a handful of good SQL books, buy it.
On a scale of stuff laying around the house, I give it 7 gold stars, half a box of binder clips, some AA batteries, and a bottle of really good soy sauce.
You can purchase SQL Hacks from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
SQL Hacks skips most of the tutelage and shows you very specific ways for doing specific chores, with more explanation of how to adapt it than theory behind it. Most hacks have database specific information for the five databases the book tackles, and many hacks are inherently different on each system, making them completely different solutions to the same problem. Those five databases are Microsoft Access, Microsoft SQL Server, MySQL, Oracle, and PostgresSQL; most of the ideas require work to adapt or are completely specific to the database system, so I wouldn't suggest straying from this supported set. The authors did their homework, and SQL Hack's strengths are the depth, detail, and level of knowledge with which each database system is covered, and the book's willingness to get down and gritty. There's never an impression that juicy details were omitted because the authors didn't want to expend the effort to pick a colleague's brain or hunt down a factoid that never got documented elsewhere. Learning how to create indices on functions with multiple arguments in Postgres was worth more than the "hack" it was a footnote in. This dedication carriers over to screen shots showing how something is done in Microsoft Access directly opposite Unix shell pipelines between grep, perl, and the SQL command shell. Most books, including mine, are a bit awkward or vague on either Unix or Microsoft Windows, but the author's and contributor's experience on this one expertly covered platforms specific database topics. Besides just database systems and platforms, the authors challenged themselves to show how to securely and efficiently use the database interfaces of a set of languages: C#, Java, Perl, Python, and PHP. The polish shows, and you'll have absolute confidence that all of the tricks really are at your fingertips, regardless of your choice of operating system, database system, or programming language.
It gets bonus points for mentioning non-obvious types of input, such as cookies, that must be sanitized or sent through bound parameters, in its discussion of SQL injections. In the security department, it looks at SQL injections from three points of view: early on in the book, correct code is shown; later, SQL injections are shown from the point of view of the attacker, with several pages of strategies and scenarios for formulating attacks; and then from the point of view of the defender, who has to defang and avoid these scenarios — extra bonus points for this comprehensive treatment.
If you're looking for a quick buy/don't buy indication, then, by all means, buy it. That is, assuming that it's not intended to be your first or only SQL book. By it's own indication, it won't teach you the basics of database normalization, installation, and so forth. I would buy it as a second SQL book, though, after the fantastic 'The Practical SQL Handbook', as it's written to a much higher standard than most books, and gets things right, such as security, the intricacies of using a database to handle accounts, and transactions and shopping carts. The cover text promises lots of advanced hackery, but that's vague. "Pushing the limits of SQL"... "Solve puzzles using SQL"... "Manage users and audit the changes they make to the database".
Here are the major sections: SQL Fundamental; Joins, Unions, and Views; Text Handling; Date Handling; Number Crunching; Online Applications; Organizing Data; Storing Small Amounts of Data; Locking and Performance; Reporting; Users and Administration; and Wider Access.
Wider Access requires some explanation. It deals with locking down the various database systems to securely providing guest accounts, or, more generally, to limit damage in the case of an SQL injection attack or similar compromise.
With some well designed tables, SQL Hacks will show you quite a few tricks, some of them quote involved, quite non-obvious, and quite clever, to extract meaning from the data. You'll probably learn quite a few new types of reports you can do — intersecting ranges from different sets of data, outputting SVG pie charts, swapping rows and columns, finding medians, computing running totals, and computing running functions such as compound interest struck me as the most useful and got mental bookmarks.
I have two metrics for this book. The first metric is whether I'd buy it if I came across it in a book store, and that's a function of whether I'd have exhausted what it had to offer after an hour or so of furious skimming and intentionally picking out the best parts from the table of contents. Very few books make this cut for me.
The other metric is whether the authors did at least what I imagine I would have done were I writing it. This test is also a difficult one but builds in a great deal of forgiveness as my ideas are quite likely dumb ones.
I totally dig the cut-and-paste ASCII query results. The authors could have easily marked all of those up in DocBook and made it prettier but also alien compared to what you'll see at the computer. They're not ashamed of the SQL command shell, and they're not ashamed of SQL.
Many hacks have several examples, covering the problem with different constraints and end goals in mind.
Multi-platform, and thoroughly so. One moment, it's showing how to use XSLT tools from the command line on Microsoft Windows, and on the next page, there's a Unix shell pipeline with wget, xsltproc, and grep. Perl one-liners abound, and there are screen shots from Windows applications with instructions for navigating the menus and setting the needed options. You won't feel shortchanged for running the "wrong" platform.
When a powerful, modern SQL extension, such as replace, gets ratified by the standards committees, the authors let you know. Sidebars are spread around sharing the good news that sometime you might not have heard of before is portable. At the same time, some features are just fluff, and you're warned off of operations intentionally left out of the SQL92 standard.
Sometimes database systems have non-portable local extensions, such as MySQL's full-text indexing and SQLServer's XML handling features, and lots of these get motioned too, usually as variations on examples demonstrating the feature as a short-cut or simplification.
The treatment of security is first rate. The polish is top notch. Writing a book is a huge undertaking, and the economics of book publishing gives publishers little margin for advances. A book that reads like it's third release but is actually in its first can only be the product of an exceptional level of dedication by the authors.
Rarely, the authors do get tutorial-ish, but only a little, and I think it works: "Choose the right join style for your relationship" deals the difference between inner and outer joins, and whether records should be partially populated with nulls or omitted entirely when relations between tables can't be made for a record. Another section shows how to convert between subqueries and outer joins, and talks about when it's possible, and this serves as a sort of lesson in demonstrating the equivalencies between the two.
The "Hacks" format is similar to the "Cookbook" format. Both offer small, randomly-accessible (flip to it when you need it) examples of how to accomplish various tasks. In the traditional, MIT circles, a hack is piece of work that's either brilliant in its simple elegance or else brilliant in its expediency and simple effectiveness, and as such, is worthy of some esteem. It's also work that's custom for a particular scenario and has limited domain — in other words, it's a highly specialized fix or improvement. If a stock fix is applied systematically, that's mechanical, not clever. By this definition, showing users how to invoke their SQL monitor, or showing users how to decide whether to use an outer or inner join, are not hacks. Few of the recipes triggered this peeve, and they were early in the book, but including those few muddles the question of who the audience is, and lowers the standard for the Hacks series, endangering its basic premise. 'SQL Hacks' isn't alone in this sin; most of the Hacks books do it to some degree.
It was written by two professors at Napier University in Edinburgh, Scotland. The style, grammar, and presentation are perfectly fine — but only that. It's not a bone dry college text book, but it was written with a dedication to professionalism that can make a technical book tedious and will certainly keep it from becoming a classic. The literary power of Brooks, Hoare, or Wall is conspicuously absent.
Authors of Hacks books are at liberty to tap the experiences of the best and brightest of the field, and the best and brightest often have tricks just too strange, clever, or specialized to fit into any ordinary sort of text. I'd like to imagine that if I were charged with writing one of these, I'd have hundreds of contributors (I'm not likable, but I am persistent). Nothing against the contributors (two of them more than 20 years experience each), but why stop at three?
I said I had two benchmarks: whether I'd be likely to walk out of a bookstore with it if I had an hour alone with it to try to get my fill, and whether it touched on the subject that I thought it should.
Before cracking the cover, I stopped to ponder what would really impress me, and what I'd like to see. The Internal Functional Programming Competition had a puzzle solved by the contest winner using SQL. I'd like to see similar combinatronics and optimization problems solved using SQL. I'd like to see a good implementations of semi-infinite-strings, the text indexing data structure and algorithm that Google uses. I've done a version of this, but my implementation leaves something wanting. When reforming badly non-normalized databases, I've had to build a normalized database in parallel and populate it from queries on the non-normalized one. It would be interesting to hear how other people approach that problem, and what I can learn from them. There are other jobs that I've tackled and managed despite never having been prepared for. Renumber a display_order priority on records in response to the user adjusting or reassigning priorities. Trees using self-joining tables is something more people should be exposed to, especially when presented with non-normalized data.
There was no semi-infinite-string implementation, but the book showed how to build full-text indexes the optimal way for each database, using built-in full-text indices and optional add-on modules offering full-text indexing. The renumbering example took the more general form of running-totals computations. There were a few examples of self-joining data, and one tree example visualized the structure. Normalizing data had tricks, including some with views, and it showed how to use Cartesian joins to do combinatronics problems. So, aside form one sort-of, the authors nailed my entire wish list. That's amazing — I've never had that happen before, actually.
The highest endorsement a book can earn from me (a cheapskate, who already has a good deal of knowledge from working the industry for ten years) is getting bought on a random trip to the bookstore where I hadn't been looking for or intending to buy anything, and paying full price on top of that. Books that are surprising, riveting, and so packed with information that I couldn't possibly copy all of the best parts down and exhaust it in an hour or two are the ones that get purchased in this manner. I have 'SQL Hacks' in my hot little hands here at home, so this benchmark is now synthetic, but... I'm somewhat undecided, and not sure whether I would or wouldn't walk out with it. More likely, I'd just put it on my wishlist and pick it up later, for a discount (I'm a cheapskate, remember). If you don't know how to do more than half of the things listed in the table of contents, most certainly buy it. If you find yourself frequently working with SQL and constantly face new problems, buy it. If you find yourself still learning SQL and wanting a variety of examples, buy it. If you're shopping for a handful of good SQL books, buy it.
On a scale of stuff laying around the house, I give it 7 gold stars, half a box of binder clips, some AA batteries, and a bottle of really good soy sauce.
You can purchase SQL Hacks from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
I tried to do "hack" sql stuff once but it kept throwing an error on "$313C7"
Dedicated Cthulhu Cultist since 4523 BC.
I tried messing around with SQL (but as you can see what happened to slashdot a while back) SQL can mess with your mind
WulframII - Free Online Mutiplayer 3D Tank Shooting Game
grep foo database.txt is all anyone would ever need.
SQL is pitted against the most difficult analysis tasks just as survival scenario books pit humans against pavement and lions.
This "survival scenario book" you're referring to sounds like it takes place at the zoo.
Push Button, Receive Bacon
Yes, offtopic, but I think it deserves to be noted that its a pretty well written review.
"Reality continues to ruin my life" - Calvin and Hobbes
Take a look at the parent's link, and you'll see the referral tag "kaleidojewel1-20".
From: http://thedailywtf.com/Articles/The_Data_Cleanup.a spx
r eplace(replace(replace(replacer eplace(replace(replace(replacer eplace(REPLACE(REPLACE(l ),CHR(5),null),CHR(6),null),l l),CHR(11),null),CHR(12),H R(16),null),CHR(17),null),, null),CHR(22),null),CHR(23),H R(27),null),CHR(28),null), ...I hope.
UPDATE OWNER_USER.all_candidates SET name = filter(translate(REPLACE(REPLACE
(replace(replace(replace(replace(replace(replace(
(REPLACE(replace(replace(replace(replace(replace(
(replace(replace(replace(replace(replace(replace(
name,
CHR(1),null),CHR(2),null),CHR(3),null),CHR(4),nul
CHR(7),null),CHR(8),null),CHR(9),null),CHR(10),nu
null),CHR(13),null),CHR(14),null),CHR(15),null),C
CHR(18),null),CHR(19),null),CHR(20),null),CHR(21)
null),CHR(24),null),CHR(25),null),CHR(26),null),C
CHR(29),null),CHR(30),NULL),CHR(31),NULL))),
why is it in every book i read, and in also reviews, the author and reviewer refer to the read or user as "her" all the time. Do they actually thing the main demographic that is reading their tech books are women? I am not a sexist here but it is a fact that IT,coding,networking is a male dominiated field.. hacking linux exposed, and hacking web apps exposed also refered to me as a woman.. ??
is to not use SQL. Seriously, at this point, with persistence systems like Hibernate and EJB3, most of us should no longer be using SQL for most database work.
SELECT * FROM database_weenies WHERE cool_factor > 0;
0 rows returned
Ian Ameline
Yes, let's all whine about software patents and then support Amazon, the leading proponent of software patents on the Web.
Where's the referral link in the parent? One can clearly see one in the next comment down, though.
I personally like the picture of the post-hole digger on the cover. I don't know if that's supposed to represent data mining tools (a pick and shovel would have been more appropos in that case) or if it's just a tool to help dig yourself out of the hole you find yourself in after 'inheriting' a DBA position.
What if the Hokey Pokey really is what it's all about?
Sounds like SQL Hacks is a kitchen sink, which may appeal to some readers.
I appreciate Joe Celko's SQL for Smarties series.
Mostly for the series pure depth, without dragging in the periphery issues or proprietary extensions.
A) Some databases are better within their own documentation demarking something non-portable.
B) The series points out commonly confused non-portable items and makes note of those in the standards that
aren't implemented very broadly or correctly in some instances.
Celko's books likewise, can be instructive to most senior developers and begginers too.
---
SQL injection, while cute and handy, is mostly a programming fault of the application and not the database.
Generally one should use better libraries and practices to make the technique moot, however languages that require more discpline abound and there are plenty of hacked applications, i.e. PHP.
How many other languages in comparison handle the proper quoting of bind variables within the library,
rather than have the application programmer assumingly do it right within their application every single
time?
At some point flexability and features can bite you in the ass security-wise, which is generally an afterthought.
Typically most applications and their associated databases, only have database security at the application or sub-system level. User rights and their groups are mostlty enforced within the application. Depending on the exact semantics of proper operation and security (usually very vague requirements, if any at all), it can become more complex than a sidebar's comments.
Hibernate etc are NOT new storage systems. They are layers on top of good old fashioned SQL databases. What happens if a Ruby script needs to access data that have been stored by Hibernate? The Ruby script, or perl script, or whatever, can use plain old SQL statements just like they always have. Hibernate uses plain old SQL databases just like everything. All it does is it saves the application developer from having to write SQL code to create, retrieve, update and delete objects.
You believe that database queries should be procedural and navigational, rather than algebraic and declarative. Tell me, if you have a sequence of Java statements in your code that perform a complex data management task, are they optimized as a unit into simpler, equivalent statements? Is it even possible? No, didn't think so. I have no idea what "procedural and navigational" vs "algebraic and declarative" means. Nor should I know. All I want to do as an application developer is do things like say, "persist this object", or "fetch all objects that have these properties". Hibernate and EJB3 can do those things for me, and I don't need to know any of this other stuff.
As for optimizing a sequence of statements into a simpler, equivalent sequence, yes that is EXACTLY what Hibernate and EJB3 do in an automated way, and they usually do a better job of it than programmers typically do, just like a good C compiler normally produces better and faster assembly language than a human can normally produce. How can computers optimize better than humans on these tasks? Well, of course humans CAN do it better just like there are some humans who can play chess better than computers, but in a normal real-world setting, computers win at these tasks.
Basically, you'd rather avoid the complexity of learning about what a DBMS is, what the underlying model is, how SQL approximates the model, and how to design a DB that can outlive it's various applications and "frameworks of the month". Yeah that's right! I certainly would rather avoid the complexity of learning about how DBMS systems work and just get straight to what I want to do, which is dealing with objects. Hey that's the same thing that happens when I program in C! I avoid knowing anything about assembly language, the ELF file format, and all that other stuff because I have some great tools that handle all that for me so I can focus on learning other things and being productive!
You support COBOL-era network databases, since I assume you're using Java, which is object-oriented, and object databases are basically network databases under a different name (more ad-hoc terminology). I have no idea what that means. I've never used COBOL. I know that when I build a EJB3 or Hibernate app, I'm using the same old databases and tables that I have always used, using the same old MySQL / Postgres / SQLServer / etc that I have always used. I just know that EJB3 looks at my classes and automatically creates good, human-friendly table definitions. I can and do open up an SQL CLI and look at what's happening in the tables, and it's just like it always was. Again I think you have no idea how these technologies (object persistence) actually work, or you wouldn't be making comments like that.
The primitive way to do object persistence by writing bits is to just serialize the object itself. Very simple Java programs can sometimes use built-in Java object serialization to store objects on disk, and then yes, those data are married to Java and can't be accessed by any other system, but Hibernate/EJB3 doesn't have anything to do with Java object serialization.
Ok, it's not entirely his fault that he's clueless. These are fairly new technologies. Anyone who does database-backed applications for a living these days should crack open some books on this!
The other day I was once again implementing yet another set of tables to represent mailing addresses, phone numbers, user names and so on; and it once again struck me as being completely ridiculous that we all don't just use the same standard schemas to do common tasks like this.
After reading the review I was expecting some pretty high level tips and tricks. I was disappointed. With few exceptions the "hacks" are things that most good DBA's already know. One saving grace of the book is that the examples are in several variants of SQL, so it's somewhat usefull as a translation guide.