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.

79 comments

  1. As a developer by jshriverWVU · · Score: 1

    Where can I send the check :) on a serious note this will be a very useful tool.

  2. Awesome by jdhawke · · Score: 3, Informative

    I have one of the wall charts up in my home office, looks great and is very handy to have as well. Great item.

    1. Re:Awesome by tlacuache · · Score: 1

      Same here. I've been working on developing a new pluggable storage engine for 5.1 and picked one of the charts up at the user's conference. Now I can just glance up at the wall for about anything I need. Saves me the 20 seconds or so it'd take to google it.

  3. Creative flow...? by Nanidin · · Score: 4, Insightful

    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.

    1. Re:Creative flow...? by drinkypoo · · Score: 1

      The mysql site has great documentation.

      What color is the sky in your world? In my world, you have to read all the comments below the pages in the manual to find the errors and downright lies in the text. Ditto for many other web-documented projects, especially PHP, whose documentation sans comments would be enough to drive you to tears.

      --
      "You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
    2. Re:Creative flow...? by Nanidin · · Score: 1

      This is true; I guess I really meant that it's easy to find function names and parameter lists (since that's what these cards are designed for.)

    3. Re:Creative flow...? by Anonymous Coward · · Score: 1, Insightful

      "I'm sorry, but if you rely on this 'creative flow' to program, your programs probably aren't that great."

      Unless you have been there its difficult for the non-creative type to imagine how this process works, but it does and its creativity in another realm and pace entirely.

      Good luck.

    4. Re:Creative flow...? by Anonymous Coward · · Score: 0

      Why this is tagged as 'funny' when it is true is beyond me.

    5. Re:Creative flow...? by panaceaa · · Score: 3, Insightful

      There is such a thing as programming creative flow. For instance, say you're coming up with a prototype for a new site. You just want to get in there, come up with a basic database that fits your needs, come up with a data API, and then write some dynamically generated HTML. If you've done it a thousand times before, it's just going through the motions and getting the code written. And if you're in this situation and you can't quite remember how to query for all rows within a specific month -- ya, it does slow you down a bit.

      I completely disagree with the spam article's premise that it'd be faster for me to go find a card laying somewhere on my desk, or that my creative flow wouldn't be broken by STANDING UP AND GOING TO LOOK AT A WALL POSTER, rather than going to the absolutely excellent MySQL documentation site, where I can actually cut and paste from examples. There's hardly ever a question about MySQL syntax or SQL functionality I can't get from the MySQL documentation. The only places where the MySQL developer guide lacks is in performance guidelines, but I don't expect that the spammed product does a better job on a laminated card.

    6. Re:Creative flow...? by saltydogdesign · · Score: 1

      If your world is really divvied into such neat boxes, I pity you.

      --
      // This is not a sig.
    7. Re:Creative flow...? by Anonymous Coward · · Score: 0

      there are rare gems in the php comments, but most of the php documentation comments drive me to tears.

    8. Re:Creative flow...? by Bobb+Sledd · · Score: 2, Interesting

      How about using an SQL front-end tool when you code? That's what I do. Problems mostly solved. Query/Insert/Update your data and copy the resulting SQL. I use EMS and even the god-awful MS SQL Server Management Studio Express, but it's better than trying to do it by hand or research. At worst you could use myPhpNuke or something (which also shows the SQL).

      --
      "They said I probly shouldn't fly with just one eye," "I am Bender. Please insert girder."
    9. Re:Creative flow...? by element-o.p. · · Score: 1

      I'm sorry, but if you rely on this 'creative flow' to program, your programs probably aren't that great.


      Nonsense.

      I agree with your argument that good programs "are the result of thought, design and effort," but I strongly disagree that disrupting creative flow is not detrimental to well-designed programs.

      I frequently write proof-of-concept code while in a state of 'creative flow' -- after taking a period of time to settle in to the job at hand and get the creative juices (so to speak) flowing, a solution or algorithm may occur to me that I had never considered before. I then begin writing code to test my algorithm, and work my way through problems that may not be immediately obvious. This is the point at which disrupting your mental state to look up some arcane syntax causes the most damage. Then, after creating the test code, I begin working on the real design, and at this point, I follow coding best-practices.

      There are several valid approaches to software engineering. Each has its own particular strengths and its own particular weaknesses. This one seems to work well for me; YMMV.
      --
      MCSE? No, sir...I don't do Windows. Yes, I am an idealist. What's your point?
    10. Re:Creative flow...? by Anonymous Coward · · Score: 0

      Proof of concept code is great. It gives my company millions of dollars/year from the DOD. We get to fix the shit we did wrong last year, by using proof of concept code, andthen we also get to write great shit on top of it with the sprial development. We get paid 2-3 times for the same code.

    11. Re:Creative flow...? by Paradise+Pete · · Score: 2, Insightful

      I don't think you've written any truly complex software. Even when you've worked out the overall solution, the details can be enormous. It requires keeping a *lot* of information "active" in your brain. It takes some time to build up that picture, and distractions can make the structure fall.

    12. Re:Creative flow...? by SirSlud · · Score: 2, Insightful

      Yeah, and while you're at it, lets ditch intellisense, visual assist, etc. When you're trying to juggle APIs from 28 different third party libaries, online docs are not the answer. Maybe "creative flow" sets off the hippy-alert for you, but having near immediate access to API signatures (ie, one second instead of twenty) is pretty much required if you are coding against lots of third party libs.

      Just because the design is finalized (or you're in a pre-design stage, as others have noted), it doesn't mean you can immediately recall that language A takes the delimiter of explode first, and the string, second, or whether that was language B. Immediate access to API expectations are a huge tool in saving time, even when writing out well architected, fully planned software.

      --
      "Old man yells at systemd"
    13. Re:Creative flow...? by GnuDiff · · Score: 1

      Sorry for flamebaiting - it is not really intended as a "my db has bigger ** than yours", but I do have to remark that since I code for both PostgreSQL and MySQL DBs occasionally, I have come to appreciate default PG online docs (compared to MySQL's default online docs) -- everything pertaining to commands/functions is concise and very well-organized.

  4. Next up by pak9rabid · · Score: 1

    MySQL Shoots and Ladders

    1. Re:Next up by pak9rabid · · Score: 1

      Seriously though, that's not a bad idea. I wouldn't mind having a small reference page of all the MySQL functions that I could easily tack on my wall next to my workstation.

    2. Re:Next up by revlayle · · Score: 2, Funny

      SHOOTS? *argh* *nooooooooo*

  5. Sweet by ObiWanStevobi · · Score: 1

    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.

    1. Re:Sweet by Anonymous Coward · · Score: 0

      You can even find functions in the list that don't exist at all namely:

      HAHA(), MADE(), YOU(), and LOOK()

      (it's in the list of 236 functions and operators they claim)

    2. Re:Sweet by BobSteinVisiBone · · Score: 1

      You're the first to find that easter egg. One of the more harder hidden.

      --
      Bob Stein, http://bobste.in
  6. Why not SQL Cards and Charts? by bunratty · · Score: 0

    I don't understand why so many SQL references contain separate sections for different DBMSs. When I write SQL, I want to write SQL, and I want to write it in such a way that it will work on whatever DBMS I happen to be using. I should be able to change to another DBMS if I need to. Why not document the widely implemented subset of SQL features, and list the DBMSs that each construct is not available on? Separate sections could list the rarely implemented and nonstandard features for each DBMS. Dammit, SQL has been standardized for twenty years! Shouldn't I able to write just SQL by now?

    --
    What a fool believes, he sees, no wise man has the power to reason away.
    1. Re:Why not SQL Cards and Charts? by Anonymous Coward · · Score: 0, Troll

      MySQL is different then other implementations.

      Other implementations are different from each other.

      Deal with it.

    2. Re:Why not SQL Cards and Charts? by DaleGlass · · Score: 2, Informative

      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.

    3. Re:Why not SQL Cards and Charts? by Anonymous Coward · · Score: 0

      What we need is a http://www.quirksmode.org/ for SQL.

    4. Re:Why not SQL Cards and Charts? by bunratty · · Score: 1

      MySQL is different then other implementations.

      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.
    5. Re:Why not SQL Cards and Charts? by bunratty · · Score: 1

      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.
      Still, it would be easier to switch from SQL Server to Postgres if I stuck with features available in both. And it would be easier to do that if the documentation listed features that were widely available, and mentioned if any of those features were not implemented in Postgres. If I have documentation specific to SQL Server only, how do I know which features will or will not be available to me if I decide to switch to Postgres later?
      --
      What a fool believes, he sees, no wise man has the power to reason away.
    6. Re:Why not SQL Cards and Charts? by tlacuache · · Score: 1

      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.

      Most of the chart is blue.

      :) Not that I'm throwing stones, but I definitely agree with where you're coming from.

    7. Re:Why not SQL Cards and Charts? by Rakishi · · Score: 1

      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.

    8. Re:Why not SQL Cards and Charts? by bunratty · · Score: 1

      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.
    9. Re:Why not SQL Cards and Charts? by BobSteinVisiBone · · Score: 3, Informative

      I don't understand why so many SQL references contain separate sections for different DBMSs. ... Dammit, SQL has been standardized for twenty years! Shouldn't I able to write just SQL by now? --bunratty

      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
    10. Re:Why not SQL Cards and Charts? by Gorlash · · Score: 1

      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.

    11. Re:Why not SQL Cards and Charts? by aztracker1 · · Score: 1

      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
  7. MySQL 5.2? by at2000 · · Score: 1

    Where can I download MySQL 5.2? http://dev.mysql.com/

    1. Re:MySQL 5.2? by dminor1958 · · Score: 1

      MySQL 5.2 has been renamed 6.0. The only difference between 6.0 and 5.1 is the Falcon storage engine. 6.0 is in Alpha. You can download it at: http://dev.mysql.com/downloads/mysql/6.0.html

  8. Not really... by skelly33 · · Score: 1

    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.

  9. Try MySQL Query Browser by Pap22 · · Score: 1

    It has a function list built-in sorted by function type.

    Screenshot (lower right):
    http://www.mysql.com/products/tools/query-browser/ qb-win-03-diff.png

    Then if you double-click the function it brings up a popup telling you the full usage + description.

  10. \h by glwtta · · Score: 1

    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
  11. Anything similar for PostgreSQL? by zooblethorpe · · Score: 1

    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."
    1. Re:Anything similar for PostgreSQL? by Anonymous Coward · · Score: 0

      I don't know of anything, but given this covers SQL 2003 which postgres implements rather better than MySQL, you could pretty much just get this and treat anything in blue with suspicion. Not perfect, but probably good enough. Failing that, why not try emailing VisiBone? While producing a real Postgres version would be hard, I can't imagine it would be much work for them to produce an (inferior) postgres version by dropping the blue statements where postgres does not support them.

    2. Re:Anything similar for PostgreSQL? by greg1104 · · Score: 2, Informative

      While it doesn't address standard SQL structures, I find most of the PostgreSQL specific information I need on the free cheat sheet at http://www.alberton.info/postgresql_cheat_sheet.ht ml

      The main things missing are generate_series, current_setting, and set_config. There are also several new system information functions in PostgreSQL 8.2; see the documentation at http://www.postgresql.org/docs/8.2/static/function s-info.html for a list.

    3. Re:Anything similar for PostgreSQL? by BobSteinVisiBone · · Score: 1

      Actually I don't recommend using this reference when developing Postgre SQL. The SQL implementations are just too different, and it would be more frustrating than empowering. I worked on this MySQL reference (and the underpinnings) on and off for two years. I'd love to do one for Postgre but at the moment the hue and cry is louder for a PHP reference.

      --
      Bob Stein, http://bobste.in
  12. Why not do a review of a services documentation? by moore.dustin · · Score: 4, Insightful

    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.

  13. documentation for the documentation-less by 192939495969798999 · · Score: 1

    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 |
  14. Excellent resource by afairch · · Score: 1

    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.

  15. What - is the Internet broken? by xxxJonBoyxxx · · Score: 1

    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.


    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?
  16. gotta catch 'em all by Ohreally_factor · · Score: 4, Funny

    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.
    1. Re:gotta catch 'em all by m0rph3us0 · · Score: 3, Funny

      The first card I will play is Silent Truncation of Data. This card renders your opponents data useless with out him knowing. Works against all known datatypes in MySQL.

      It is ineffective if your opponent had already played "Upgrade to Postgresql".

    2. Re:gotta catch 'em all by Paradise+Pete · · Score: 1
      The first card I will play is Silent Truncation of Data.

      Oh man, you should have saved that for the bonus round.

    3. Re:gotta catch 'em all by Anonymous Coward · · Score: 0

      Yeah but the Postgres card has to already be in play, he can't play it in response.

      Because as we all know it's not an instant, and all MySQL cards resolve faster.

  17. Ooo, a slashvertisement! by raehl · · Score: 3, Insightful

    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!!!

  18. Re:Why not do a review of a services documentation by Anonymous Coward · · Score: 0

    Uh, for starters -- this isn't a book.

  19. Sites CC payment is dead by vlm · · Score: 1

    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
    1. Re:Sites CC payment is dead by BobSteinVisiBone · · Score: 1

      Actually you did already buy it. Sorry, the CC payment is not dead, just creaking a bit. All fixed, we'll ship your chart tomorrow.

      --
      Bob Stein, http://bobste.in
    2. Re:Sites CC payment is dead by vlm · · Score: 1

      There's something uniquely cool about customer service via slashdot

      --
      "Science flies us to the moon. Religion flies us into buildings." - Victor Stenger
  20. Cho? by Anonymous Coward · · Score: 0

    is that you?

  21. Free MySQL Cards & others by toddhale · · Score: 2

    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

    1. Re:Free MySQL Cards & others by Andrew+Ford · · Score: 2, Informative

      That web site will be going away sometime soon. Most of the stuff is on, or linked to from, refcards.com. There are currently about 60 cards listeed, including MySQL.

  22. I didn't read the review by rho · · Score: 2, Interesting

    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.
  23. Newbie alert. by Anonymous Coward · · Score: 0

    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?
    Ah, the innocence of youth. Isn't it cute?
  24. This is degrading. by Mr2cents · · Score: 1

    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
  25. http://gotapi.com/ by amazon10x · · Score: 1

    http://gotapi.com/

    A bunch of stuff from C++ to the Flickr API. It has a nifty search as you type thing.

    1. Re:http://gotapi.com/ by Mr2cents · · Score: 1

      It sounded cool, but all the links give me a 404 error and a bunch of ads. I'll check again later.

      --
      "It's too bad that stupidity isn't painful." - Anton LaVey
  26. Cards and Charts so low tech... by mysidia · · Score: 1

    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)

  27. ILoveJackDaniels.com cheat sheets by Chris+Pimlott · · Score: 1

    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.

  28. Alternate Review by UNFAIRMAN · · Score: 1

    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".

  29. rumors of CC payment death, greatly exaggerated by BobSteinVisiBone · · Score: 1

    I can tell you it sure feels great on this end.

    --
    Bob Stein, http://bobste.in
  30. MySQL cheatsheet by Neeth · · Score: 1

    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.
  31. Database Tips by Grindalf · · Score: 0

    I always write my own database when developing software - that way you always know how it works and can customise infinitely without looking stuff up. TOP TIP!

    --
    The purpose of existence is to make money.
  32. IDE with code completion / on-line help is better by harmonica · · Score: 1

    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?

  33. Hardcopy is slow by General+Wesc · · Score: 1

    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.

  34. Visual Stimuli by kattrap · · Score: 1

    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.