MySQL: Building User Interfaces

Craig Maloney writes "If you are a Windows programmer looking to create or move your stand-alone database applications away from Microsoft-specific tools such as Visual Basic, Visual C++, Access or SQL Server, MySQL: Building User Interfaces is written just for you." Read on for the rest of Craig's review.

MySQL: Building User Interfaces
author	Matthew Stucky
pages	632
publisher	New Riders
rating	4/10
reviewer	Craig Maloney
ISBN	073571049X
summary	MySQL and GTK+ are used to create cross-platform applications, with copious code listings.

What's in the book?

The first chapter guides the reader through the basics of MySQL and how it compares to Access 2000 and SQL Server 97. Next, a code listing demonstrates the basics of connecting to MySQL via C using the MySQL C API. the book gives an all-too-brief whirlwind tour to the basics of MySQL. The next four chapters are a tutorial on how to use GTK+ and GLADE, focusing on how these toolkits are similar and different from their Visual Basic counterparts. GTK+ was chosen in this book because of its cross-platform compatibility with both Windows and Linux / UNIX operating environments. The second part of the book takes what was learned about MySQL and GTK+ with GLADE and uses it to create a stand-alone application (a real-world order-entry application).

What's Good?

Throughout MySQL: Building User Interfaces, Stuckey describes exactly what he is doing and why he is doing it that way. The introduction to GTK+ in the first part of the book describes just about every GTK+ widget available (menus, buttons, sliders, status bars, etc.), and creates a monster busy-box application (not to be confused with the busy-box application by Bruce Perens) demonstrating those widgets by themselves. Later in the book Stuckey uses Glade to put applications together, but not using Glade early on gives the reader a chance to see what is happening under Glade's abstraction. During the building of the order-entry application, Stuckey explains the design decisions behind the widgets. Each window of the application is introduced first with a diagram describing where the widgets will be followed by the code for each widget. The design looks like a Visual Basic application designed by a a programmer, with an eye toward the functional rather than the aesthetics of user interface design, but as an introduction to GTK+ programming it works well.

What's Bad?

If there was ever a book that required a CD-ROM to accompany it, this book gets my nomination. Authors have to walk a fine line between presenting code snippets that don't make sense by themselves, or risk boring readers with page after page of code that might confuse readers who aren't yet ready to view full code listings. MySQL: Building User Interfaces chose to include the full code listing for everything. This is both a blessing and a curse: readers have the code right in front of them and don't have to worry about being in front of a computer while reading the book, but the flow of the book is interrupted every time something is introduced.

The descriptions also suffer, because those code listings are expected to explain in more detail what is going on. In the GTK+ introduction, widgets are introduced with short paragraph introductions. The real-world application, which should be the focus of the book, reads like an assembly line: A screen is introduced, the widgets are placed, and the code is listed. Worse, files which make little sense without a computer (such as files generated by glade) are presented along with the code listings. This makes reading this book a chore. Thankfully, there is an FTP site with the code ready to use, but future versions of this book would be best served to include it on disc.

Perhaps a balance can be struck in a future edition where important code concepts are highlighted without sacrificing seeing the code in a meaningful context.

So, what's in it for me?

Windows programmers who need a hand in getting their applications to Linux or UNIX may find this book helpful (but overwhelming) as they learn. This book stands out as a bridge for Windows programmers to make their transition to Linux and UNIX smoother, but the emphasis and amount of code listings in this book may make Windows programmers choose a different route.

---

You can purchase MySQL: Building User Interfaces from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

Re:Try SQLite

[Anonymous Coward]

Can someone expand on the difference between a stand-alone db and one that needs a service to be installed? I just don't understand what the differences are between Access and other databases such as mySQL...

I'd give it at least an 8

[Anonymous Coward]

I've been working through this book for quite some time, and now that I've extracted all i can I have to declare myself delighted with it. The examples are good, deep enough to convey the lessons but shallow enough that not too much is irrelevant. I now have, as the author promised, several applications that will compile easily under both linux and win32. If i can fault the book at all , my only reservation is that is would have been nice to see all the necessary software included on the cd. Downloading all of the required applications and libraries (particularly for windows) led to a treasure hunt accross the web. That aside I would recommend this book to anyone who is not new to programming and databases, a little prior knowledge will be required as this is definately not a complete beginners book.

Re:Try SQLite

[gandy909]

I suppose the app could easily be written to start the server when it starts and shut the server down when it ends, thus not wasting resources all the time...couldn't you? Not that mysqld is a resource hog anyway...

Locking Problem

[stoolpigeon]

from the sql lite page it looks like multiple users can select silmultaneously but only write to the database one at a time. Locking for writes is not record level, page level or even table level - it is the whole database.

Too bad- because MySQL really does not replace Access but neither does this- unless it will only run internally to one user.

A bit easier than programming GTK directly...

[tcopeland]

...might be to use a higher level language wrapper like Ruby/GTK [sourceforge.net].

Prototyping an app will probably take less time if you don't have the compile/link cycle... worth a try, anyhow.

Re:Try SQLite

[w00t_sargasso]

So... You are telling me that Microsoft Access, or at least that part of it _necessary_ to read mdb's will fit on the floppy as well?

I like MySQL because it _is_ a server -- You can create any application in (almost) any language on any platform (think php) to interface with a MySQL database. Try telling me that you can do that with access.

And you _can_ also fit a SQL db on a floppy.

To sum:
-You cant fit M$ Access on a floppy, but you can a db.
-You cant fit MySQL on a floppy, but you can a db

-MySQL is free (and all applications do remain PROPRIETARY provided they dont modify the MySQL source in any way -- Read the licence properly dudes.
-M$ Access is NOT Free in ANY interpretation of the law (to test, try telling Microsoft that it's free...)

Rekall

[bstadil]

Rekall [rekallrevealed.org] is another Access like Frontend that works with MySQL and a few others.

They got shafted by TheKompany and need some help so download it a send a few bucks their way if you like it. Runs on Linux and Windows.

I suppose this is flamebait or a troll but...

[kahei]

...wouldn't the effort be better spent in actually bringing mySQL up to the point where it *can* replace SQL Server?

MySQL seems to occupy a rather subtle and narrow niche, perhaps the 'single smallish website' niche. I can't really imagine wanting to use it when most applications are liable to grow beyond that niche.

PostgresSQL looks a lot more encouraging, feature-wise, although it doesn't seem to offer many concrete benefits over SQL Server. Still, to me, a book on migrating to PostgresSQL or another full-featured RDB would be more useful.

Re:Both are replacements for MS SQL Server

[Valar]

MySQL has transactions. It has for QUITE awhile. In fact, I write code that uses MySQL transactions everyday. Stored procedures are availible (will be availible?) in version 5.

Re:Try SQLite

[millahtime]

wait, who still uses a floppy. The only time I have used one of those in the last 4 years is an ftp install of reebsd. other then that, what use is there?

Re:Locking Problem

[stoolpigeon]

No. You can have multiple concurrent users doing all kinds of crap and the locking granularity can be down to the record level if you write your code correctly.

Now the one thing that is bad with access is that if a user drops their connection in the middle of something it has a tendency to blow up. If you have a lot of people using an Access file over a network- you are going to need to compact & repair every so often. But I've seen stuff go strong for a while with 30-70 users hitting the same .mdb for 10 hours a day and it worked pretty well.

Re:Both are replacements for MS SQL Server

[skiflyer]

PostgreSQL was one of the two, and it has stored procedures, triggers, and views. I believe it has it's own version of sequences, just as MySQL does. (Which I personally prefer to MS SQL's)

Re:Both are replacements for MS SQL Server

[ttfkam]

For varying definitions of "quite a while." Other than that I would agree with you except for the fact that every table involved in the transaction must be an InnoDB table. Have a half-and-half setup? When that transaction rolls back, the InnoDB tables will remove the changes, but the MyISAM tables will still be changed. ...not that MySQL will tell you this. No. Once again, it will do it all silently without even a warning to let you know that you need to convert one more of your MyISAM tables to InnoDB.

Which doesn't even cover the fact that if you are being hosted by an ISP, using their copy of MySQL, and you type in:

CREATE TABLE foo (
...
) type=innodb;

and they are either (a) running an older version of MySQL or (b) disabling support for InnoDB tables because of their noticeably higher overhead than MyISAM (yes, both cases happen quite regularly), you will be none the wiser.

MySQL will not issue a warning, error, or valentine's day card for your troubles. So here you are, happily SQLing away without a care because you have InnoDB tables until you notice some strange data...because...you aren't running InnoDB tables after all.

Be honest, how often do you run the following?

SHOW CREATE TABLE foo;

Everytime you create a table? No?

How about the next statement? Here we attempt to give some users on Slashdot 10% more of a clue.

UPDATE slashdot_users SET (clue = (clue * 1.1)) WHERE preferred_db = 'MySQL';

and (oops!) something went wrong halfway through for some reason. Maybe someone killed the process. Maybe someone kicked a cord. Maybe you ran out of memory on the box and the process crashed. The world is an imperfect place. Back to work though: how many Slashdot users had their clues upped? If they were updating a MyISAM table that "didn't need transactions," we have no idea.

Transactions aren't just BEGIN and END statements. They aren't just commit() and rollback() functions. They are intrinsic to a valid datastore. They are the Atomicity in ACID. That UPDATE statement was a transaction in all contexts used to describe databases.

MySQL and transactions are like assembly language and for-loops. They can be made to go together, but they were not originally designed for such a task. In assembly, it's a set of well-placed jump (goto) statements. In MySQL, it's a set of table=innodb flags. Some people do it the hard way for no good reason even when easier, less error prone methods exist. For the rest of us, we use a higher-level language or -- in this case -- a higher-level database. If and only if we see a need to optimize do we drop down to assembly (MySQL). You don't start with assembly and then try to find rationales for a higher-level language.