The Practical SQL Handbook: Using SQL Variants (4th ed.)

Continuing the grand tradition of reviewing computer texts sent to us by publishers, Slashdot author chrisd has read the book The Practical SQL Handbook: Using SQL Variants and written up a review. If you are interested, read on ... The Practical SQL Handbook, 4th Edition, SQL Variant author Judith S. Bowman, Sandra L. Emerson, Marcy Darnovsky pages 512 publisher Addison Wesley rating 9 reviewer chrisd ISBN 0201703092 summary An indispensable introduction to SQL. This is probably one of the best books I've read for those new to SQL. It's the kind of book I wish I had many years ago when I was first learning about databases. The only problem is the SQL variants are not really for me, a developer uninterested in Oracle, MS-SQL, Sybase or Informix. That said, this is a minor part of the book and doesn't really detract from it, and I can even come up with any number of reasons why a developer would want to have that information. A comparative text would be useful by itself, but I think that trying to teach SQL and several SQL variants is too big a job for any one book.

The books introductory text on SQL is clear and concise. I also found its treatment of normalization to be as close to perfect as can be with one exception: It doesn't tell when you can go too far with normalization. In an introductory text this is acceptable, and perhaps wise considering what many new to relational databases consider acceptable database design.

And while the introductory chapter is great, the chapters on selects and joins is so clear and useful that I would even call it exciting. The terrific thing about this book is when you have finished reading it you should come away with a feel for how the underlying DB actually works and what it is doing to produce the data for you.

I personally found this book very useful, even though I am using MySQL for the application I'm writing. But the feature set that MySQL chooses to support will logically limit the usefulness of the this book for the MySQL user. Programmers developing for Postgres, Firebird, and others will obviously get much more out of the book and its treatments on subqueries and views than will MySQL users.

One thing that did turn me off is the inclusion of a CD-ROM. The CD has a copy of Sybase for the user to work with. I don't need to explain that the internet is a superior place to put such things. That said, at least it wasn't glued to the back cover (a pet peeve) and was instead bound into the book like a magazine reply card. Many publishers perceive that they can charge more for a book that has a CD, but I just find it annoying and wasteful. But that's hardly a reason not to buy this book and place it on your bookshelf in a prominent position, not on the bottom ghetto shelves next to the stack of paper for your printer.

In short, those looking for an book about SQL, that won't teach them bad habits would be well served by this book (and likely by its sister book, The Practical SQL Handbook: Using Structured Query Language by the same authors) and those who think they know SQL will find it a useful text to have handy as well.

You can purchase The Practical SQL Handbook: Using SQL Variants from bn.com. Slashdot welcomes readers' book reviews -- to submit yours, read the book review guidelines, then visit the submission page.

Comments

Is the sequel better?

[tomknight]

I note that this is the 4th edition - is this one of those times that the sequel is better than the original?

Tom.

Re:Is the sequel better?

[alapalaya]

the sequel is better than the original

or, maybe:
the SQL is better than the original

(OMG, I need an holiday....!) :)
Cheers.

Re:Is the sequel better?

[wackysootroom]

No, But the SQL is much better!

Re:Is the sequel better?

[bhsx]

It's actually the first book, then they're releasing the 5th and 6th versions. We'll see the 1st, 2nd and 3rd in about 25 years.

Well-done book

[lseltzer]

I read an earlier edition and have a very high opinion of it. It's not an intro to database programming, but it will get you from nothing to very far into SQL.

Re:Well-done book

[Skweetis]

Have to agree with you there. This book, along with a pretty sad looking copy of "Programming Perl", never makes it from my desk back to my bookshelf because I refer to it regularly for the obscure bits of the syntax that I can never remember. Now that the fourth edition is out I'll have to upgrade, since edition three is in about four pieces because the binding broke on the frequently used pages.

Not much different.

[Anonymous Coward]

I have the 3rd edition and was actually flipping through the 4th edition a couple of days ago at the bookstore. I honestly didn't see any big differences at all, certainly not enough to justify buying another copy.

Personal Opinion

[Cinnibar CP]

As pretty much the local DBA-by-default among the developers here, I would say that having this manual, or an earlier edition similar to it, in the hands of the average programmer is invaluable. It gives them the basics of SQL theory across the multiple databases we work with and reduces the number of SQL-related questions I have to deal with.

For DBAs and advanced SQL programmers, however, I would recommend database-specific manuals that give greater insight than an overview text such as this, as this type of manual is unavoidably poor in the more important aspects of query optimization. Jack of all trades and master of none, as the case usually is.

Decent review, BTW (+1 INTERESTING, article moderation)

Excellent!!!

[baldass_newbie]

The CD has a copy of Sybase for the user to work with.

A free coaster!

SQL Limitations ?

[smak]

I'm just getting into SQL myself - at least I've got perl talking to a mysql database :)

During a web-search for help with SQL, I came across a discussion, which said that SQL had many limitations (I don't have the link anymore.)

I've found SQL reasonably powerful so far, but obviously I'm new to this stuff.

Can anybody point out the areas that SQL is lacking in ? (and maybe where new progress is being made.)

Just interested.
Cheers.

Re:SQL Limitations ?

[Entrope]

SQL is particularly weak if you have definite but flexible hierarchy -- for example, say that you have relations like this between objects:
Obj1 (type A) "owns" Obj2 (type B) and Obj3 (type C)
Obj2 (type B) "owns" Obj4 (type C)
There is no particularly good way to model this relationship in SQL; you need at least four tables (one to establish ownership relations and act as object identifiers, and three to define the traits for types A, B and C) where you would ideally want only three.

Another weakness is when implementing "business logic" -- rules that define whether or not particular changes are allowed, or what else must change to keep things consistent. In the past (I believe SQL99 improves this, but is not widely supported yet), there was no standard for defining smart triggers, constraints or stored procedures, and some database systems did not support such things at all. One common solution to this problem is to have a layer of code in front of the database that performs all of the transactions and reports business logic violations to its clients -- the classic three-layer database system, but not as efficient or clean as if the business logic could be handled by the database system itself.

There are some other application-specific weaknesses; for example, a full inverse text index cannot be stored both efficiently and portably in SQL. This has impact on things like DNA sequencing as well as text searches.

On-line analytical processing is also somewhat limited within the standard; this partly goes back to the lack of a standard trigger language, and partly to the traditional table/row model of a SQL database.

SQL is a very powerful and very useful standard, and its existence as a standard has done an incredible amount of good. It does not solve every problem -- but given how complex the standard already is (and has to be), that may be a good thing.

Re:SQL Limitations ?

[reemul]

Not such a good example - you can model that with just three tables. One each for types A, B, C, and add an "owned by" column to the B and C tables. It's many-to-many relationships that need separate tables to map out how items interrelate, a simple "is owned by/child of" just needs a column.

Business logic should be separate from the database, with triggers and stored procedures used primarily for data integrity issues. (Which is why the poor-to-nonexistent support for transactions and foreign key relationships make MySQL a sad also-ran for many purposes compared to the expensive proprietary options. But I still hope...) You can get some significant performance benefits to putting some often re-used procedures into the database, but that doesn't make it a best practice for all circumstances. It's overused by both lazy front-end programmers who can't be depended upon to validate the input they are accepting and bored DBAs who are trying to look busy. And such items are some of the least portable code you can write for different database systems, whereas table creation and select/insert/update commands work pretty much anywhere. Doesn't mean SQL is perfect, but if your problem comes from trying to get it to do things that properly should be done somewhere else, the failure is in the design, not SQL.

Re:SQL Limitations ?

[Tablizer]

(* In my first example, take "owning" to be whatever you mean: the hierarchical structure of a document, organization of a company or device, and so forth. *)

I think the concept of "owning" is anti-relational in philosophy. "Own" is only one possible viewpoint (relationship) among *many*. One should not hard-wire such absolutisms into software designs. (OO often does this with overbearing IS-A relationships.)

(* Many real-world relationships have the required trait *)

Example? IMO, trees are over-used in computer-science. They conceptually are (initially) pleasent to work with, but fail to capture the multi-facetted nature of most real things (besides animals and shapes) well over time. You end up getting deeper and deeper into your speggetti vine. If you follow any man-made change pattern over time, it will almost certianly digress from a true tree. (Technically, you can force just about anything into a tree, however, it becomes artifical over time, often having to duplicate nodes or at least a vast majority of a node.)

Even in a "hierarchical document", you may want to search for things in a non-hierarchical manner. The "hierarchy" is just one viewpoint among many. (Plus, some complex documents cannot be easily reduced hierarchically.)

True, some niche domains can take advantage of its limited pathways. CAD may be one.

Re:SQL Limitations ?

[Slime-dogg]

The real area where SQL is weak is recursion. There is no allowance for recursion in '92 and there is little I believe in '99.

An excellent language to examine is Datalog, which uses rules to do queries. The structure of the Datalog language, as well as it's queries, falls very close to the definition of a finite state machine.

You can show the flow of data, and how it fits within the bounds of the rules you give it, all by drawing the states that you define within the language. The query ends when it reaches a point where it can no longer process any data.

SQL is great for database work, but I honestly believe that the future lies in a rules-based language like Datalog.

Re:SQL Limitations ?

[alienmole]

SQL is excellent as far as it goes, but it doesn't provide a complete solution to all data processing requirements. (If you've ever written stored procedures that are just hundreds of lines long, you have an idea of what I mean).

Which means that for complex processing, there has to be an interface at some level to a more flexible programming language. The dominant programming model in business today is object-orientation - not without some good reasons - but unfortunately, there are some problematic issues in mapping between object and relational systems.

So the problem with relational systems is really simply that (a) in themselves, they are not appropriate for all data transformations and (b) they don't easily lend themselves towards integration with more flexible systems.

That said, I agree the most developers don't seem to be aware of what SQL can do. Having personally developed systems that included tens of thousands of lines of SQL, I'm pretty familiar with what it can do, but also with how restrictive and inflexible it is compared to some other approaches. One of its biggest problems is that it lacks a powerful enough reuse mechanism, and the various proprietary extensions don't do a very good job of correcting this.

Glad they emphasis SQL-92

[pmancini]

SQL-92 has much better syntax than SQL-89. I just wish more of it was implemented. MS SQL-Server actually does a better job of it than even Oracle. Compare

Select A.*
From A,B
Where A.MayorName is not null
and A.CityID = B.CityID
and B.TaxRate > 5

vs.

Select A.*
From A JOIN B
ON (A.CityID = B.CityID)
Where A.MayorName is not null
and B.TaxRate > 5

The major difference is that the join is explicityly removed from the filtering done in the where cluase. This makes queries much easier to read. Queries can get extreamly complex and when you have something like 6 joins you will soon appreciate the new syntax.

This book sounds interesting so I will be checking it out!

--Peter

Re:Glad they emphasis SQL-92

[eric2hill]

"MS SQL-Server actually does a better job of it than even Oracle."

Oracle 9i now supports the SQL-92 syntax including natural joins. If you want to join two or more tables that have properly named keys (like key names for PK/FK relationships), then you can use the following:

select *
from A
natural join B
where A.MayorName is not null
and B.TaxRate > 5

It's a very nice way to join a lot of properly normalized tables with little to no WHERE clauses. SQL Server can probably do the same thing as well.

Re:Glad they emphasis SQL-92

[irix]

This makes queries much easier to read

Really? As a programmer who has used Oracle for years, I find the SQL-92 style join syntax more confusing. I spend a lot of time getting it correct when writing SQL for RDBMS who use that join style.

I suppose maybe it is just what you are used to.

Re:Glad they emphasis SQL-92

[FearUncertaintyDoubt]

As far as readability, I think it's a matter of preference (i.e., what you were "raised" on). FWIW, I like the JOIN because it separates your joins from your filtering.

The one big reason to use SQL-92 (why we do it at my job) is because it effectively prevents an accidental cartesian query:
SELECT * FROM table1, table2

if table1 and table2 each have 1000 rows, you just selected 1,000,000 rows. 10,000 rows each, that's 100,000,000, and you get the point. You can easily crush a server by making a typo.

While the above query is a trivial example, easy to overlook that you didn't join properly, especially when you start complicating it with > 2 table joins with lots of WHERE critieria. If you always use explicit SQL-92 JOINS, your SQL won't run if you don't join properly.

Re:Glad they emphasis SQL-92

[Caractacus Potts]

I'm actually a fan of the JOIN clause. You might think that it's easier to read when you're writing it, but things change when you have to deal with more complex queries or decipher a long unformatted one that you or someone else wrote long ago.

I'm currently coding up a SQL "pretty printer", and moving the joining criteria from the FROM clause where it makes sense to the WHERE clause where it's just convenient does not look pretty.

Re:Glad they emphasis SQL-92

[FearUncertaintyDoubt]

SQL-89:
SELECT * FROM table1, table2
WHERE table1.id = table2.id

SQL-92:
SELECT * FROM table1 JOIN table2
ON table1.id = table2.id

Re:Glad they emphasis SQL-92

[jabbo]

You know, that may well be, but I always thought that the "where a.id = b.id" was pretty logical and explicit. I still can't quite bring myself to use the new syntax except for outer joins (where, at least in Postgresql, it's the only way I know of to do it).

I have worked on and developed on MySQL, Oracle, Sybase, PostgreSQL, and a tiny bit of MS-SQL (7.0) so I have a few bad habits stemming from my Oracle days. I do like Postgres best of all, though.

Re:Glad they emphasis SQL-92

[Fulcrum of Evil]

Did they fix the bug where circular joins crash the DBc connection?

SELECT A.id FROM A, B, C
WHERE A.id = B.id AND B.id = C.id AND C.id = A.id;

Re:Glad they emphasis SQL-92

[Pfhreakaz0id]

As a guy who learned SQL on MS-SQL (the -92 variant), going to Oracle now, this has been my biggest hurdle. I have to mentally translate it back. I don't see how anyone could argue it is clearer to separate the joins from the filtering. In practice, I think most people puts joins first, then filters, but I've read some stuff that it might not always be the most efficient query.

I understand 9i now supports JOIN, but we're still running 8. SIGH.

SQL Security

[mrkitty]

www.cgisecurity.com/lib Has some good papers on sql security.

Another good book

[Giant Robot]

The only deadtree book I've read on SQL is:

A First Course in Database Systems (2nd Edition)
- Jeffrey D. Ullman, Jennifer D. Widom

I found that it covers almost everything I needed, with a no-nonsense approach (no "CheckPoints", long pointless blurbs, or long code listings).

Although written for the academic, it didn't stop me from reading mostly the second half of the book first (the SQL stuff), and reading some theory when I wanted to.

The SQL it covers is pretty standard stuff that works with most databases (except for MySQL at the time I read it, some ACID principles couldn't apply). The specific details for each databases can be picked up by reading online docs.

If you visit SE-asia, check out their bookstores where you can find tons of "mainland china" editions of these classics that cost a tenth of the price as the real deal.

MySQL again

[fm6]

I don't want to start the "is MySQL a real RDBMS" debate again. Well, maybe. Anyway, it seems a little strange for a discussion of advanced SQL to center around MySQL. The only serious defense I've heard for MySQL is that it handles very simple queries more quickly than other engines. If you're a serious doing a database app that requires you to think about normalization, you probably need a database that's smart enough to optimize a complicated query.

CDs everywhere

[fm6]

The CD has a copy of Sybase for the user to work with. I don't need to explain that the internet is a superior place to put such things. ... Many publishers perceive that they can charge more for a book that has a CD, but I just find it annoying and wasteful.

Well perhaps. Certainly most "FREE BONUS!" CDs are a total waste. But having a large DBMS server on a CD can be a real boon for those with slow internet connection. You'll not that many sites that provide software for free download also offer the same software on CD for a nominal fee.

Also, increasing the "perceived value" of the book is porbably only part of the story. Undoubtedly AW got some kind of consideration from Sybase for advertising their product this way.

Compare to /Visual Introduction to SQL/ ?

[sphealey]

How does this compare to A Visual Introduction to SQL? The first edition of that book is the best into to SQL and (indirectly) relational databases I have seen. The first edition didn't cover outer joins, though, and before I buy the second edition I was wondering how the reviewed book compares.

sPh

Re:Very controversial book

[gazbo]

Although you can do some replication work yourself, I'm happy to concede that if you want the work done for you you need thrid party software. To say that Postgres doesn't support it is a bit misleading though.

Postgres doesn't support automated replication in the core code but there are open source plugins that will handle this. Equally, PHP does not support gzip functions as part of the core language, but should this be highlighted as a shortcoming of the language? No - just install zlib et voila!

I don't care whether the automated tools come with the core download or not - if they're freely available and work cleanly with the code (not dirty hacks) then there is no problem. Nested subqueries in MySQL is a problem as there was no (as far as I could google) patch I could apply that would enable this functionality. This is not true for pg replication.

A chapter on the shortcomings of Postgres wrt replication would be half a page long and consist of a list of URLs, saying "install one of these".

This is SQL-99, not SQL-92, and it's in Oracle 9i.

[emil]

According to Daniel K. Benjamin's "Oracle 9i New Features For Administrators Exam Guide," Oralce 9i introduces:

1. The JOIN keyword with its variants
2. CASE statements (a subset of which were supported in 8.1.6)
3. NULLIF
4. COALESCE
5. MERGE
6. Various analytic functions

Oracle has a lot of problems, but standards conformance is not one of them. Oracle is one of the few databases to have certified with NIST for SQL-92.

Titles? Editions? Sequels?

[fm6]

its sister book, The Practical SQL Handbook: Using Structured Query Language by the same authors.

Uhm. Despite the change in the title, I believe this is an earlier edition of the same book. No idea why it's still in print -- perhaps some people prefer to focus on SQL-89 and forget about SQL-92. Anyway, you're probably thinking of Practical SQL: The Sequel

Re:That's because

[dillon_rinker]

There's a big difference between SQL and DOS or RAID...VOWELS!

Hands on, limits of

[fm6]

Get a copy of whatever database you're going to use....Next, look at a database that someone else has written and attempt to manipulate the data through queries.

I suspect most database programmers learn that way. Which is actually a bad thing. Not that hands-on experience isn't important. But a lot of databases seemed to be designed by folks ignorant of the most basic concepts of relational theory. Many such programmers could stand to do a little reading. If Practical SQL Handbook is a decent mixture of theory and practice (I'm certainly gonna give it a look), it's probably sometime all those self-taught database designers should be reading.

Re:Hands on, limits of

[fm6]

I would plug 'Database Management Systems' by Ramakrishnan and Gehrke for a more theory oriented approach to databases on an advanced undergraduate to 1rst year grad student level.

Problem is with books like that: they're basically useless unless you're (a) in some kind of academic program, and have good instructors and smart fellow students to help you get some kind of real-world context or (b) your name is Doogie Houser!

Re:That's because

[sphealey]

In fact, until about 1992 or so "SQL" was pronounced "ess-que-ell" in US English. About the time Microsoft "SequelServer" was released it suddenly became "Seek-kwell". Don't know why, but it does tend to grate on those who used it before change.

sPh

Why Sybase?

[puppetman]

Closed source, proprietary.

Why not Postgres 7.2 for the Linux crowd, and Firebird (Open Source version of Borland's Interbase db) for the Windows crowd.

Lots of graphical tools available, and not that difficult to set up (compared to Oracle, anyway).

Both implement all features that a modern relational database are supposed to support.

Re:Why Sybase?

[bad-badtz-maru]

Postgres 7.2 implements all of the features a modern relational database is supposed to support? How about master-master replication? Even master-slave replication is only supported through third-party patches that do not scale well. The open source databases (postgres, mysql) are poorly scalable and this lack of scalability makes it impossible to even start to compare them to their commercial counterparts.

maru

Re:Why Sybase?

[mesocyclone]

Why not Postgres 7.2 on Windows? I use it all the time. You don't need to go to Firebird.

Re:Why Sybase?

[puppetman]

Postgres under Cygwin is slow, and can be more difficult to setup and maintain (so says the people posting to the PostgresQL.org lists).

Re:Why Sybase?

[puppetman]

I'm an Oracle DBA, and while it's easy to setup, it's difficult to set up correctly.

And last I heard, Oracle is not free. We pay $14,000 per CPU every 2 years.

Re:Why Sybase?

[puppetman]

"Books like this probably target people who will go to work for some company that will be using a closed database since they need that added functionality. (and can afford it)"

The book is on SQL, not tuning, or database administration. As most databases are mostly SQL 92 compliant, it should be a non-issue.

Re:Why Sybase?

[puppetman]

Replication is not a feature of a relational database (modern or otherwise). It is a fail-over/load-balancing feature that exists in many products (networks components, application servers, message queues, webservers, etc).

For learing SQL, I fail to see how master-master replication is going to help.

Re:That's because

[edhall]

SQL != SEQUEL

Although SQL is largely derived from it, SEQUEL was the query language of IBM's first Relational Data Base Management System, System/R, dating back to the mid-1970's. (IBM's second --and current -- RDBMS was creatively named DB2.) So pedantic old farts like me are careful to distinguish between the two and pronounce SQL as ess kyoo ell to avoid confusing it with its more primitive predecessor, SEQUEL (though it's not like there is any real chance of confusion these days).

-Ed

No good

[fm6]

Most of us have matched set coasters with an AOL theme.

Good Suggestion for T-SQL

[stoolpigeon]

And learning T-SQL is a good idea if you want to work for someone who uses SQL Server. (Which is a lot of people- so more power to you)

But lets say you want to run a database for yourself or you are a smaller company. Then I would not recommend worrying too much about learning a variant of SQL tied to an expensive propietary system. (SQL Server only runs on MS NT or 2000- and so you've got server licensing, db server licensing and then seat licenses for everyone who will connect to the db)

At my small company we looked at expanding a product so we priced a new server- and then SQL Server licenses for that server and 200 users. The licensing on the software was much more expensive than the hardware we wanted to buy.

Our solution? We are going w/PostgreSQL. It has some very nice visual tools for management. It has good ODBC support. And it has most of the capability that SQL Server has. Enough to justify taking advantage of the monetary savings.

And Oracle? Forget it- more expensive than SQL Server.

Granted there are businesses out there where the cost of Oracle or SQL Server is more than justified- but those huge companies are a minority of the business world. There are many more like us- not huge but we need good RDB systems.

.

Re:Good Suggestion for T-SQL

[rnd()]

excellent... i'll have to look into postgres in more detail... do you know if there is a tool out there similar to MS query analyzer and enterprise manager that will work with postgres?

I just like to be able to go in and modify tables and look at recordsets easily...

Re:Good Suggestion for T-SQL

[stoolpigeon]

I'm just getting into this myself.

At this point I've been using PGAdmin II. It is open source written in VB (yeah - I use VB and I'll admit it). It gives you the ability to do quite a bit of what you can do in enterprise manager.

There are other tools that I have not used yet that will work on multiple platforms. The postgreSQL has great documentation and links to many of the useful tools. This is one project where it is very, very easy to find what you need to get the ball rolling.

PostgreSQL can not do everything SQL Server and Oracle can do. As of right now you cannot back up transactions. I believe it is also limited in regards to replication and some other features that the big boys handle pretty well.

But in many cases, like ours- we don't need that stuff. I just need a dependable rdbms that doesn't cost an arm and a leg and isn't a piece of crap like MS Access.

.

Re:SQL books

[EastCoastSurfer]

Both SQL for smarties books rock. Joe Celko does a excellent job at showing why SQL is not as easy as everyone thinks. Showing the 3 different queries that get the same data, but are more or less efficient is very helpful in broadening your understanding of the language and how it works.

Re:Very controversial book

[Luyseyal]

you mean like:
http://dmoz.org/Computers/Software/Databases/Pos tg reSQL/Replication/
http://techdocs.postgresql.org /oresources.php#repl ication

None of these appear to have Master-Master replication support.

-l

Re:That's because

[jafuser]

Some acronyms are easier spelled than pronounces

According to many dictionaries, it's not really considered strictly an acronym unless it is easily pronouncable; otherwise, it's just an abbreviation. Personally, if it's an abbreviation where the letters are the first letters of most of what it's abbreviating, I call it an acronym whether it's pronouncable or not.

As far as what to call "SQL", I think most of us are intelligent enough to know what someone means if they say either "ess cue ell" or "sequel".

I am one with google. I also bother to _read_.

[Luyseyal]

I did google for those. I also bothered to read the project statuses for each one. PostgreSQL-R critically lacks:

• support for replicated DDL
• support for version 7.2.x

Whether they support a Master-Master configuration or not (which, you'll note, is not even mentioned on the site), it's not near finished enough to compete with Sybase et al. in this particular, but important area.

-l

Re:I am one with google. I also bother to _read_.

[mi]

Does Sybase support master-to-master replications? I don't think so :-( Master-to-slave -- yes, though...

-mi

Naw

[fm6]

Such thoughts are not healthy. They lead you to accumulating useless crud on the off chance that it's "collectable". I'm not even going to talk about those "commemorative editions"...

I do wish I had bought California real estate when it could be had for 5 figures. But I thought it was too high....

Why even need explicit joins?

[Tablizer]

As long as you specify the tables involved, the DB engine can easily figure out the primary join paths (if you set it up right). It seems to me that is better factoring than to repeat the relationships over and over.

Only when you are doing something different or odd should the joins need to be explicitly stated, and only incrimentally. (I know some DB's already support something like this, but it should be standardized IMO.)

Then again, if we are going to change SQL, then perhaps overhaul it completely (another thread below).

Re:mod this up

[Splork]

why did some moron mod this down and give it a troll rating? he makes a perfectly good observation asking a perfectly good question.

SQL Aternatives (was: SQL Limitations ?)

[Tablizer]

(* Exactly. Poor design is not an excuse to blame SQL. SQL is math. Can math solve bad design? *)

But there are different ways to "math" the same thing. For example, Relativity and Quantum Physics may solve certain problems, but sometimes old fashion Newtonian physics can do it quicker, have a shorter learning curve, and be 99.99999999 percent as accurate.

If I replaced SQL, here is some draft suggestions:

http://geocities.com/tablizer/relat2.htm

My biggest complaint is that SQL is too nested-based, whereas, I would rather see it be reference-based. Graphs are more general-purpose than trees. Plus, being able to isolate the name-space into smaller chunks would be helpful IMO.

Re:Why Mods Suck?

[stoolpigeon]

I don't complain about moderation much but sometimes you can only take so much.

I would love to here from whoever moderated my post as Flamebait and have them explain some reason for that. There's nothing I said that isn't accurate and parts of it are posted all over this thread.

I guess I committed the cardinal sin of posting something that did not toe the party line. How freaking pathetic.

I like the moderation system and I like to moderate- but some times I just get pissed when some idiot who knows absolutely nothing mods someone down.

I think modding down should burn 2 points and modding someone up should burn 1. Too many people are way too free w/off topic, redundant, troll, etc.

So to the faceless, ignorant moderator of my post let me just say - You Suck.

(yeah - its friday I've got some time on my hands and I do feel better now. That's worth a little karma)

.

Re:my suggestion

[rodgerd]

TORA is open and supports MySQL and PostgreSQL as well as Oracle.

SQL in a Nutshell helpful for variants

[billmil]

As for keeping track of sql variants, I recommend Oreilly's *SQL in a nutshell*. It's helped me quite a bit developing a vendor neutral app that runs on both Oracle and SQL Server. (It covers Postgres and MySQL also).

As the reviewer posted, learning sql and learning the various flavours IMHO is too much for one book. The Nutshell book is a reference for advanced users.

Re:That's because

[wdr1]

SELECT * FROM accurate WHERE SQL != SEQUEL
No rows returned.

Actually, what most everyone knows as SQL and Sequel are the same thing, at least in the same sense that SQL-86, SQL-92, etc. are the same thing. (I.e. there are obvious enhancements, etc. to the language as time passed and it evolved, but the language itself is still what we think of as "sql".)

IBM changed the name from SEQUEL to SQL in the late 70's as SEQUEL was found to be an existing trademark.

-Bill

T-SQL != MS SQL Server

[Tadghe]

Actually Transact SQL is not completly tied to M$ SQL Server.

You'll find it used with at least some versions of Sybase.

Remember M$ SQL Server's History (purchased from Sybase, indeed they were Paying Sybase royalties until 7 IIRC).

That being said, while I try and stick as closely to SQL89/92 as possible, I would say that TSQL with it's extentions is not nearly as much of a PITA as PL/SQL.

Re:That's because

[edhall]

Like my post said, SQL is largely derived from SEQUEL, and the latter is the "more primitive predecessor" of the former; that's essentially the relationship you describe. And you're right about the reason for the name change (though the odd thing is that the conflict was with the name of an airplane -- IBM's lawyers must have been paranoid in those days). But we were discussing the name, and the pronunciation of the name. Check out the following document on the history of SQL:

• The 1995 SQL Reunion: People, Projects, and Politics

You'll note that the originators of SEQUEL/SQL are very careful to use one term or the other depending upon which point in time they're discussing. That the name change corresponded to some pretty significant additions to the language is probably why in circles outside of the creator's group SEQUEL and SQL are often treated as separate but related entities. But whether or not they are the same language misses the point: they are two different names, and as the above article shows, SQL was named in the style of other three-letter-languages of the era like APL (by "squeezing the vowels out of SEQUEL"), and was pronounced accordingly. This is why old farts (especially IBMers and ex-IBMers) are quick to correct whippersnappers who pronounce it SEE kwell.

-Ed