Slashdot Mirror
MySQL Cards and Charts
Michael J. Ross writes "Database programmers using MySQL frequently have a need to verify the name or parameter list of a MySQL function, or to check a statement or the data types available within its implementation of SQL. This typically occurs when the programmer is caught up in a coding session, and would much rather not break their creative flow by searching Web sites for the needed information, or stepping away from their computer to hunt for a reference book. In these cases, nothing could be more valuable than a concise summary of all SQL statements and MySQL functions, in a form compact enough to be kept within reach on the desk or tacked up to the nearest wall space. This is the goal of the VisiBone MySQL Cards and Charts." Read on for the rest of Michael's review.
MySQL Cards and Charts
author
Bob Stein
pages
4
publisher
VisiBone
rating
10
reviewer
Michael J. Ross
ISBN
N/A
summary
High-quality reference materials for MySQL functions and SQL statements
These two products contain the same information, with the same formatting and color coding. They differ primarily in their construction, sizes, and likely destinations. The MySQL Cards — often referred to as cheat sheets — are 8.5 by 11 inches in size, made of card stock that has been laminated on both sides of each pair of cards, for a total of four pages of information. The MySQL Chart is 24 by 33.3 inches, printed of course on only one side. The VisiBone Web page devoted to these products notes that the cards have the advantage of portability, while the chart has the advantage of presenting all of the information in one glance. (The Web site fails to mention that the large chart has the additional advantage that it can be used to cover blemishes on a wall, such as those caused by a Web programmer banging his head against it when wrestling with browser incompatibilities.)
The March 2007 edition of the cards and chart cover MySQL version 5.2 and ISO/ANSI SQL 2003 specification. Such a tremendous amount of technical information needed to be packed into relatively small form factors, offering limited space — especially compared to books. Consequently, all of the available space had to be used judiciously. That is precisely what Bob Stein, principal of VisiBone, has accomplished with these items. Each one diagrams the syntax for 84 SQL statements and 236 MySQL functions and operators. In a private communication, Mr. Stein noted that no fewer than 194 of MySQL's 225 reserved words are included. (Of the remaining 31 reserved words, 7 are apparently not used anywhere in MySQL, 13 are quite obscure, and 11 are functionally synonymous with other terms — mostly column types from other database engines.)
Given the small amount of space available, there would be the danger of the material being difficult to read. Fortunately, Mr. Stein utilized shades of gray, white and black, blue (to indicate MySQL statements that are not standard ISO/ANSI), and the occasional red (to indicate the most commonly needed information). He also made full use of space on the right hand side of each page, for the largest sidebars, and the remaining space in the middle, for more modestly sized topics. Lastly, he chose a readable type size of 9 points.
The MySQL Cards present the SQL statements and MySQL functions separately, each on their own cards, in alphabetical order. The SQL statements are less horizontally linear and more diagrammatic, to indicate alternative and optional keywords. For each function, the return data type and parameters are given, as well as a pithy summary of what the function does, or an illustrative example. There are a total of 182 examples of the functions and operators, all tested.
The MySQL Chart includes the identical information provided by the cards, but with all of the SQL statements listed down the left-hand side, and all of the MySQL functions down the right-hand side.
Reviews of technical materials oftentimes focus exclusively on the product itself, with no mention as to its delivery. That might make sense for a technical book that could be ordered, packaged, and shipped from any one of many online bookstores, or purchased in person at a local bricks-and-mortar bookstore. In contrast, these MySQL products, like all other VisiBone products, are packaged and shipped from the company's only location, in Brunswick, Maine. The smaller size of such an operation allows for greater attention to each individual shipment. Furthermore, the cards are mailed in sturdy cardboard flats, with directions not to be bent. Charts are mailed in double-hulled cardboard tubes that are even more sturdy.
It is rare that one encounters such excellent products in the fast-paced world of technical publishing. However, I can offer just two minor suggestions for improvement. Even though the color choices generally work quite well, the medium gray used as the background color is probably not the best choice, since almost all of the text is in black. A lighter shade of gray — perhaps that used for a couple of the sidebars, such as "GROUP_CONCAT()" — with a corresponding change in those sidebars, would make the text stand out more.
The only other weakness I found was the use of the term "Habitat," as an adjective for "Shell," "PHP," and "Web Browser." The meaning may be immediately obvious to those of greater intelligence than myself (not that that narrows the field), but my presumption was not confirmed until I saw mention of the term on the aforesaid Web site. The term "Sample" would be more clear.
The chart is the ideal size for a poster, and the 8.5"x11" cards work well; but if the cards were folded into two or three panels, they would be easier to stand up on a desk, and not get buried underneath papers and books.
Nonetheless, the overall quality of these cards and charts is outstanding; the information they offer is accurate, up-to-date, and neatly presented; the protective packaging was appreciated. Even the levity was a nice touch: Despite the limited unused space on the cards, Mr. Stein manages to still squeeze in a bit of humor concerning ISBN bar codes.
Looking over these materials would, for anyone non-technical, probably cause their eyes to glaze over. But for the dedicated MySQL programmer, it can be a humbling experience, largely because it reveals just how little of the language is known or used on a regular basis — by most database programmers, or, at least, by this one. Slowly perusing the information-rich pages, I found myself delighted to discover for the first time functions and statements that would allow my future MySQL code to do more natively, within uncompiled statements, stored procedures, and triggers, without resorting to performing the processing within PHP or whatever other application language will be used.
Lastly, each shipment is accompanied by a letter from Mr. Stein, in which expresses to the customer his appreciation for their order, and his genuine excitement in the potential that any developer has to use his tools to help develop something great. He makes clear that the focus of his efforts is to create "visualization technology for web designers" that will help them do their job better.
Although these items are not books, the VisiBone MySQL Cards and Charts could easily replace the typical MySQL reference book for most occasions when a question of language syntax needs to be resolved as quickly and conveniently as possible. I especially recommend the MySQL Cards, not only for the wealth of information, but for the way that it put all of it "at mental fingertip reach."
Michael J. Ross is a Web programmer, freelance writer, and the editor of PristinePlanet.com's free newsletter.
Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
The March 2007 edition of the cards and chart cover MySQL version 5.2 and ISO/ANSI SQL 2003 specification. Such a tremendous amount of technical information needed to be packed into relatively small form factors, offering limited space — especially compared to books. Consequently, all of the available space had to be used judiciously. That is precisely what Bob Stein, principal of VisiBone, has accomplished with these items. Each one diagrams the syntax for 84 SQL statements and 236 MySQL functions and operators. In a private communication, Mr. Stein noted that no fewer than 194 of MySQL's 225 reserved words are included. (Of the remaining 31 reserved words, 7 are apparently not used anywhere in MySQL, 13 are quite obscure, and 11 are functionally synonymous with other terms — mostly column types from other database engines.)
Given the small amount of space available, there would be the danger of the material being difficult to read. Fortunately, Mr. Stein utilized shades of gray, white and black, blue (to indicate MySQL statements that are not standard ISO/ANSI), and the occasional red (to indicate the most commonly needed information). He also made full use of space on the right hand side of each page, for the largest sidebars, and the remaining space in the middle, for more modestly sized topics. Lastly, he chose a readable type size of 9 points.
The MySQL Cards present the SQL statements and MySQL functions separately, each on their own cards, in alphabetical order. The SQL statements are less horizontally linear and more diagrammatic, to indicate alternative and optional keywords. For each function, the return data type and parameters are given, as well as a pithy summary of what the function does, or an illustrative example. There are a total of 182 examples of the functions and operators, all tested.
The MySQL Chart includes the identical information provided by the cards, but with all of the SQL statements listed down the left-hand side, and all of the MySQL functions down the right-hand side.
Reviews of technical materials oftentimes focus exclusively on the product itself, with no mention as to its delivery. That might make sense for a technical book that could be ordered, packaged, and shipped from any one of many online bookstores, or purchased in person at a local bricks-and-mortar bookstore. In contrast, these MySQL products, like all other VisiBone products, are packaged and shipped from the company's only location, in Brunswick, Maine. The smaller size of such an operation allows for greater attention to each individual shipment. Furthermore, the cards are mailed in sturdy cardboard flats, with directions not to be bent. Charts are mailed in double-hulled cardboard tubes that are even more sturdy.
It is rare that one encounters such excellent products in the fast-paced world of technical publishing. However, I can offer just two minor suggestions for improvement. Even though the color choices generally work quite well, the medium gray used as the background color is probably not the best choice, since almost all of the text is in black. A lighter shade of gray — perhaps that used for a couple of the sidebars, such as "GROUP_CONCAT()" — with a corresponding change in those sidebars, would make the text stand out more.
The only other weakness I found was the use of the term "Habitat," as an adjective for "Shell," "PHP," and "Web Browser." The meaning may be immediately obvious to those of greater intelligence than myself (not that that narrows the field), but my presumption was not confirmed until I saw mention of the term on the aforesaid Web site. The term "Sample" would be more clear.
The chart is the ideal size for a poster, and the 8.5"x11" cards work well; but if the cards were folded into two or three panels, they would be easier to stand up on a desk, and not get buried underneath papers and books.
Nonetheless, the overall quality of these cards and charts is outstanding; the information they offer is accurate, up-to-date, and neatly presented; the protective packaging was appreciated. Even the levity was a nice touch: Despite the limited unused space on the cards, Mr. Stein manages to still squeeze in a bit of humor concerning ISBN bar codes.
Looking over these materials would, for anyone non-technical, probably cause their eyes to glaze over. But for the dedicated MySQL programmer, it can be a humbling experience, largely because it reveals just how little of the language is known or used on a regular basis — by most database programmers, or, at least, by this one. Slowly perusing the information-rich pages, I found myself delighted to discover for the first time functions and statements that would allow my future MySQL code to do more natively, within uncompiled statements, stored procedures, and triggers, without resorting to performing the processing within PHP or whatever other application language will be used.
Lastly, each shipment is accompanied by a letter from Mr. Stein, in which expresses to the customer his appreciation for their order, and his genuine excitement in the potential that any developer has to use his tools to help develop something great. He makes clear that the focus of his efforts is to create "visualization technology for web designers" that will help them do their job better.
Although these items are not books, the VisiBone MySQL Cards and Charts could easily replace the typical MySQL reference book for most occasions when a question of language syntax needs to be resolved as quickly and conveniently as possible. I especially recommend the MySQL Cards, not only for the wealth of information, but for the way that it put all of it "at mental fingertip reach."
Michael J. Ross is a Web programmer, freelance writer, and the editor of PristinePlanet.com's free newsletter.
Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
Where can I send the check :) on a serious note this will be a very useful tool.
I have one of the wall charts up in my home office, looks great and is very handy to have as well. Great item.
I just read the description to where it says "programmer is caught up in a coding session, and would much rather not break their creative flow by searching Web sites for the needed information, or stepping away from their computer to hunt for a reference book." I'm sorry, but if you rely on this 'creative flow' to program, your programs probably aren't that great. Good programs aren't the result of quickly written code - they are the result of thought, design, and effort. The mysql site has great documentation. Google will fill in the gaps if you're in need. The creative portion of the programming process should be well done before the code starts hitting the screen.
MySQL Shoots and Ladders
Would be nice to have such a list for all databases. Then again, it would be nice to have a list for all programming languages too. Then my wall would be covered in various colored charts and finding the right one would cause that same break in concentration I wished to avoid anyway. In reality, I think the web search is still the better choice in most cases. You can also find useful hints for functions that you don't find in any book or chart. Sometimes the break in concentration leads to some accidental learning that makes your program better.
Where can I download MySQL 5.2? http://dev.mysql.com/
There's no need to "search the web" for mysql references - mysql.com has excellent, comprehensive documentation online, and it is supplemented by commentary of programmers who actually use the stuff every day. It would take me longer to locate and flip through a book than to get the answer from the source especially when I'm already at the keyboard. Another consideration is that the online documentation could be updated where the book is frozen to a specific point in time. I agree that there are uses for certain types of reference books, but this one I'll pass on.
It has a function list built-in sorted by function type.
/ qb-win-03-diff.png
Screenshot (lower right):
http://www.mysql.com/products/tools/query-browser
Then if you double-click the function it brings up a popup telling you the full usage + description.
I don't know what MySQL calls it.
(though if you frequently need a reference for freaking SQL statements, I think there might be something wrong with you)
sic transit gloria mundi
These look like they'd be quite useful. Does anyone out there know of something similar, only for PostgreSQL instead of MySQL?
"What in the name of Fats Waller is that?"
"A four-foot prune."
Why not review the documentation of the subject at hand before posting and trying to sell books to people when better resources are available for free? If /. posted a review of PHP/MySQL documentation , people would be able to see that they do not need to buy these books. That would help the users here save money as opposed to ripping them off so the site can get a small cut.
Invexi - a Phoenix, AZ based web design and web development company.
The main problem with that is that even if SQL was 100% standard, databases still have different behavior. For example, if you tune something for MS SQL Server, performance will suck on postgres and viceversa. If you try to make it run well on both, it'll run suboptimally on both.
For instance: MS SQL Server 2000, as a database that uses locks, likes small transactions. The smaller the better. A long running transaction in MS SQL is potentially troublesome. Big transaction locks row, another connection waits on that, another connection waits on the second one, and so on. Database grinds to a halt until the big transaction is done.
On the other hand, postgres has a high overhead for creating a transaction, but once that's done, the more you do there the better. The same long running transaction in postgres won't create any problems in postgres due to MVCC. Now, if you use postgres where nearly every database query is one sentence in its own transaction, then performance won't be impressive.
I understand that different implementations are different. But I want to avoid what's different, and try to use what's widely implemented so I can switch DBMSs if necessary. For that, wouldn't it be most useful to have the widely implemented features of the SQL standard documented, along with which DBMSs do not implement those features? That would document the differences you mention. Then, in a separate section, the rest of the features, the more different ones, of each DBMS could be listed. That would document the rest of the differences. However, documenting them this way would encourage me to stick with features that many DBMSs support, rather than writing for the specific DBMS I happen to be using, then getting stuck when I need to switch to a different implementation.
To clarify, I'm not asking for MySQL's implementation to be the same as every other DBMS, or every DMBS implementation to be the same, anything about the implementations at all. I'm requesting that the documentation of SQL to focus on what is a standardized subset of SQL so I can write portable SQL. Isn't that why a SQL standard exists?
What a fool believes, he sees, no wise man has the power to reason away.
so these are for if you built a bunch of sql stuff and didn't document it, right? Because why not just look in the documentation on the functions, unless there is no documentation.
Documentation isn't an afterthought, it's supposed to be the blueprint for what you build (just like a house). How is the team in agreement on what's being built without something written down?
The mind boggles at how people get so close to documenting their systems and yet still miss many of the benefits.
stuff |
What a fool believes, he sees, no wise man has the power to reason away.
This company also has a set of HTML and CSS charts available that I purchased a couple of years ago, and have found to be extremely useful on a few occasions. When I found out that the MySQL cards were being produced, I ordered them immediately and was not disappointed. While the online MySQL documentation may be excellent, I find these cards to be well worth the money, and sometimes more convenient.
I've got the VisiBone MySQL chart, and its items are either blue or white. White is standard SQL, and blue is stuff MySQL has added.
:) Not that I'm throwing stones, but I definitely agree with where you're coming from.
Most of the chart is blue.
What - is the Internet broken?
I remember some of the more clueless people (e.g. English majors) pulled into IT in the late 90s resorting to primitive measures like this, but really, would anyone really do this in 2007?
Not only is it useful, but it can be really fun, if you're an uber geek. Imagine getting together with your fellow uber geeks for a rousing game of MySQL the Gathering. (Sadly, I'm not an uber geek, just a smart ass.)
It's not offtopic, dumbass. It's orthogonal.
Database programmers using MySQL frequently have a need to verify the name or parameter list of a MySQL function
Ok...
or to check a statement or the data types available within its implementation of SQL.
Still with you...
This typically occurs when the programmer is caught up in a coding session,
Really? I usually run into this problem when I'm watching television.
and would much rather not break their creative flow by searching Web sites for the needed information,
If I wrote that most database programmers would not care to spend their evening with Natalie Portman and some grits, would that make it true?
or stepping away from their computer to hunt for a reference book.
Yeah, because I bet all those MySQL database programmers have no idea where their MySQL reference book is. I bet they have to spend a whole 3 seconds reaching to the shelf behind them, or typing 'mysql <command name>' into Google.
In these cases, nothing could be more valuable than a concise summary of all SQL statements and MySQL functions,
How about a beer?
in a form compact enough to be kept within reach on the desk or tacked up to the nearest wall space.
How about a beer on a shelf?
This is the goal of the VisiBone MySQL Cards and Charts
The card might make a good coaster.
Also...
1. State the existence of a problem. (Actual existence not necessary)
2. State the lack of solutions to problem (Actual lack of solutions not necessary)
3. Submit statement to Slashdot until read by lazy editor.
4. Profit!!!
paintball
Would love to buy one if I didn't get the following error:
Credit Card Error - The bank did not seem to approve that transaction.
Also sets off noscript's cross site scripting error.
"Science flies us to the moon. Religion flies us into buildings." - Victor Stenger
Check out the great refcards website!
http://old.refcards.com/refcards/index.html
It has free refcards for:
AMSTeX
Apache
Catalyst NEW (21 July 2005)
C
Emacs calc
cvs
emacs
gdb
mod_perl
Perl regular expressions
Template Toolkit
TeX
XEmacs
MySQL
HTML DOM
XHTML 1.0 frameset
XHTML 1.0 strict
XHTML 1.0 transitional
CSS level 1
CSS level 2
XPath
XSL
XSLT
XML TopicMaps 1.0
Very slick indeed.
Todd
I can only assume that people found the standard to be lacking in features. So each DB added it's own things to increase the feature count, etc. Of course they all did it independently so you get a lovely mess where each database may do X but the syntax is different for each.
Because of this:
and would much rather not break their creative flow by searching Web sites for the needed information,
I don't get that assertion at all. I keep a PostgreSQL, PHP and ADOdb tab open for my various projects. Looking through those manuals is a lot more helpful and a lot easier than a cheat-sheet. When I'm looking up something, it's because it's non-trivial, and I'll need context and examples. Or I want to do something odd, and I'm wondering if there's already a handy function or query that does what I need (SELECT FOR UPDATE to lock a row, as a simple example) so I don't have to programmatically reinvent the wheel. I guess if you need to recall the order of an UPDATE clause this might be helpful, but otherwise, no.
Besides, there's barely enough room on my desk for the laptop and a martini. I'd have to hold the cheat-sheet in my mouth.
(On a side note, I've been using Panic's Coda since they released 1.0. It's pretty swell. Their "Books" feature, though, is significantly less useful than the Web manuals. The PHP manual is particularly unhelpful compared to the Web version.)
Potato chips are a by-yourself food.
Now if only they could make this in the form of website... or maybe a suppository. Hmm...
"It's too bad that stupidity isn't painful." - Anton LaVey
http://gotapi.com/
A bunch of stuff from C++ to the Flickr API. It has a nifty search as you type thing.
I don't understand the response to this question. I have learned dozens of programming languages, usually ones that have different implementations. When I read them, they do not contain different chapters on different implementations. In C++ books, they discuss C++ and perhaps talk about implementation differences between compilers. For example, they say that an int is a data type that can hold integer values between -32768 and 32767, and can possibly hold larger and smaller values. They may even give examples of some different compilers and their different ranges for ints. But they don't contain completely separate sections on Visual C++ and GNU C++.
Why don't SQL books just explain SQL? Shouldn't I just be able to write SQL code that runs in any DBMS with minimal changes just the way I can write C++ code that compiles with many different compilers and runs on many different OSes with minimal changes? Does it seem like a stupid question? Even so, could someone answer why so many SQL references contain separate sections for different DBMSs, making it difficult to write portable code? Why not just explain SQL and give the differences between different implementations within the same section, instead of covering MySQL, SQL Server, etc. as if they're separate languages?
What a fool believes, he sees, no wise man has the power to reason away.
I'd rather see MySQL have an intuitive online help interface. Built into the command interpreter. I.E. SQL statements would be used to look up the reference
I envision something like mysql> SELECT help_snippet from mysql.functions where name like '%myfunctionname%' \G Result: help_snippet: (text describing the function)
You know I really intended to make a comprehensive SQL reference from the start, covering MySQL, Microsoft, Oracle and possibly Postgre. And I stubbornly held onto that goal for 80% of the project. But I gave it up for two reasons. For one, researching MySQL took so long, I knew the release would delay another year if I researched Microsoft, Oracle and Postgre as well.
But the more compelling reason was the vast quantity of MySQL-only features. (Actually the delay was more compelling, but this incompatibility issue is a more noble-sounding justification.) Not just the quantity of unique features but their astonishing vitality (e.g. string comparison). Hardly any real world SQL application can avoid breaking with standards.
I think it's more accurate to say "the effort to standardize SQL has been going on for 20 years" rather than it was accomplished twenty years ago. And I don't think it will feel accomplished for many years hence.
I think there are many reasons for this long hard road, but one is that the cost/benefit of standards for SQL is unusually skewed. Getting a practical database application to work well is monumentally complex (so the benefits of advanced and intricate ad-hoc features are high). A lame database, unlike a lame rounded corner, can lose customer work and destroy goodwill (so the cost of diligent standardization can be high).
Furthermore, SQL development is rarely concerned with more than one engine at a time. Stored procedures, and other features supporting reusable code, are going through a tortured adolescence (so the benefits of portability are still low). Finally (for reasons related to the preceding, impacting industry maturity), every dialect today has a thriving single company or community in stewardship (so the costs of flaming individuality are low).
So as far as a cheatsheet, I don't think a universal SQL cheatsheet would be as valuable as one that presented all the powers of the specific SQL for the task at hand. MySQL came first because the most people asked for it. Especially passionately I might add.
Bob Stein, http://bobste.in
ILoveJackDaniels.com also has a number of good "cheet sheet" references, mostly focused on web applications/web design: CSS, PHP, MySQL, Javascript, VBScript, mod_rewrite, HTML, HTLM character entities, RGB hex color codes, Ruby on Rails, Microformats, and (now for something completely different) World of Warcraft.
I've been using VisiBone products for years and I love them. So when Bob sent me an oh-so-friendly email about his new MySql Cards, I forked over my credit card info right away. I've been using my new cards for 30 days now. Here's my alternate review:
The cards come as 2 laminated 8.5x11 duplex sheets. Visibone's JavaScript and HTML cards are also 2 sheets, but they are connected at the spine to make a mini book, and in the case of the JavaScript cards each page has a unique border color. These small details makes a huge difference. I'm constantly flipping these MySql cards around to find the right page.
Each page has a title, such as "Statements H-Z". Unfortunately these titles aren't at the top! One is close to the top, one is in the middle of the page, and the other two are close to the bottom, making it more difficult to orient yourself.
The colors are very nice, but aren't taken far enough. There are lots of boxes all round such as "Legend", "Terminology", and "Regular Expressions" placed wherever there is room on the page, but they don't stand out. Again, see his prior work.
I have no quibbles with the content he chose to put on these cards. Kudos.
The biggest problem I have is the alphabetical approach. Often I'm coming back to MySql after a day coding Oracle statements, and I can't remember what MySql calls a particular function. I don't know the name, so printed alpha isn't much help. To correct this Bob should pull out all the date/time functions into a group, all mathematical functions in another group, etc. At the risk of sounding like a broken record, this is what he did on his JavaScript card (but not his HTML card).
I would still rate the product highly, but this version isn't a "10".
Writing database-independent code is, to be blunt, in almost every case a stupid move. How often do you change databases in the real world? Almost never. Database independence is writing to the least common denominator, and really just ensures that you're never going to perform well on -any- database. A far more useful approach is to write database-specific modules that perform well on the database they're written to support, and can be (if it's ever really necessary) swapped out with a module for your new database.
I can tell you it sure feels great on this end.
Bob Stein, http://bobste.in
I always use this cheatsheet:
If you want to select records use: SELECT
If you want to update records use: UPDATE
If you want to delete records use: DELETE
If you want to use a database use: USE
This list can also be used with other db systems.
Yes, I am the one with the legendary sig.
Charts are all fine, but isn't the ideal solution an IDE which shows type information to the developer entering the code, like Eclipse does with Java, Visual Studio with C# and C++, and so on?
It would be nice.. but anything beyond the simplest select/insert/update/delete queries will be different... There are variances to column types available, how/if to setup views, and stored proceedure language/syntax can vary dramatically.
Even a semi-complex query with a limit of rows to return can vary from one implementation to another. Compound this with the fact that MySQL wasn't even created to be a standards compliant database, and a lot of the compliance is tacked on, and even then breaks in certain cases.
PostgreSQL is designed to be very standards compliant, but doesn't really follow a lot of the syntax you may see in MS-SQL, DB2, Firebird or Oracle...
General SQL doesn't apply at all to mysql, and will have some issues in any other dbms. For the most part select/insert/update/delete work the same, until you get to joins, transactions, and more complex programming such as CREATE * and ALTER * syntax for procedures, tables, and views, which can be dramatically different. This is why most programs that are written for more than one database either expect an interface api to be implemented for that database, or run tend not to run very well..
Michael J. Ryan - tracker1.info
If locating the information on a hardcopy cheat sheet is faster than locating it using Google, either you have the slowest dial-up ever (or no IC--in that case, sure), you're the slowest typist ever (how long does it take to type a search query?), or you've memorised the exact location of every item on the cheat sheet, in which case you don't need it anymore: you have it memorised.
I use reference books, textbooks, &c a lot, but not for a quick lookup of a command I need right now.
The one thing that I haven't seen anyone comment on is the visual nature of the chart/cards. I'm the type of person that will remember what section of a poster will have the information that I'm looking for. I'm going to hang the poster right next to my great poster of networking stacks.