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.

Try SQLite

[hendridm]

MS Access has the advantage (on Windows machines anyway) of being a stand-alone database without needing a service to be installed. For a app where you don't want to have to install MySQL server and have it waste resources, you might consider SQLite [sqlite.org]. Unlike MySQL embedded, it's release under the public domain. MySQL Embedded is licensed under the GPL and has the following requirement [mysql.com]:

... any program which includes, by linking with libmysqld, the MySQL source code must be released as free software (under a license compatible with the GPL).

Although, depending on what you want to do with the software, this may not be a problem. I'm all for free and open source software, but a brother's gotta eat too.

more sellers

[tedtimmons]

amazon link [amazon.com]

isbn.nu link [isbn.nu]

half.com link [ebay.com]

No affiliate tags are used above. But here's the amazon link [amazon.com] with my tag, if you feel generous.

My opinion

[W32.Klez.A]

I have read this book, and used it to my advantage. However, they don't properly explain some parts about what you're doing, and why you're building the interface. I was hard pressed to find the exact reasoning they used for some of the things they did, but other than that, it's a great resource for mysql developers such as myself.

Make sure you use MySQL version = 4.0

[spun]

Before that, the dang thing doesn't support nested subqueries, or any kind of subqueries on inserts and deletes. Found that out the hard way recently (the docs don't make it very clear) and had to rewrite a bunch of elegant SQL as less elegant Perl loops and wacky joins.

Still, I love MySQL. Postgres is more full featured, but for the smallish web-based applications I write, it's overkill.

Kexi is also worth checking out.

[anonymous coword]

It is an open source program similar to Microsoft Access [kexi-project.org]. It works with MySQL too. It even runs on Windows.

Re:Try SQLite

[man_of_mr_e]

Access is simply an application. When you open the database, it's just like opening a file in a word processor.

MySQL is a service that runs seperately from the application and must be started and stopped seperately. In most cases, the service is started at boot time and runs all the time, wasting resources unless you manually stop it.

I read this book

[Anonymous Coward]

Recently I had to write a mysql demo for a tradshow. I had
never worked with mySQL before. I got this book and was
able to complete a full fledged demo in a matter of three
days, working part time. The book is very well organized,
easy to read and understand and best of all the examples
work without modifications. I highly recommend this book
for beginners. I would have done so for all levels but
I'm not an advanced user of mySQL.

If you're thinking of getting started on mySQL this is the
book.

Re:MySQL Feature Set

[Anonymous Coward]

another interessting read is here. [sql-info.de]

Re:Try SQLite

[Mod Me God Too]

I do a little DB development. The basic difference is a DB system like MySQL, Oracle or SyBase is that the 'DB' is the back-end (indeed it is a server-type process) which is interrogated by SQL statements (the front end may be built in C++, VBA, whatever), whereas something like Access is an all-in-one solution with the back-end and the front-end in the same app mish-mashed together (it may purport to be SQL-like, but only from within the app, not as a server) - I think MS still provide Foxpro as Access simple can't hack really big work. So an SQL-type database is the classic client-server, Access and Paradox don't seperate front and back ends (they say they can be split, but that is a bit of a bodge job).

Wikipedia has a more thorough discussion here (for SQL) [wikipedia.org] and here (databases in general but quite a read) [wikipedia.org]

Re:Try SQLite

[AndroidCat]

Hmm. Access is an application which uses the underlying MSJET engine. Anything that can create an ADO object (or OLEDB or DAO...) can use that engine without Access running. The engine also handles reference counts so that if more than one program is using it, it won't load multiple copies and it won't unload until the last one closes it.

Re:Try SQLite

[cscx]

Actually, I think you may have been mislead if I read you correctly. Another person in the thread was correct when they said that Access is a front-end to the actual Access database. You can run SQL queries against an Access database... the functionality is built into the driver.

One minor correction

[The Bungi]

There's no such thing as "SQL Server 97". There's SQL Server 6.5, 7.0 and 2000. Perhaps he's referring to 7.0? Well perhaps he should have referred to the newest version instead.

Not that I'd be interested in a comparison between MySQL and SQL Server (midrange C/S replacement for Access/FoxPro - OK. Enterprise RDBMS? No)... but still.

Re:Try SQLite

[torok]

MySQL will *never* be a replacement for Access

I am in complete agreement.

I write small DB apps for small businesses. My clients all have MS Access installed. I would love to be able to use all open-source tools to develop these apps, but so far nobody can show me something that's as simple for my computer-illiterate clients to install as "Here, copy this .mdb file to your hard drive and double-click on it". Installing one more piece of software wouldn't be hard either, but if I have to say "Here, install OpenOffice first, then install MySQL, make sure it's running, then run this script to put the right data in MySQL, then make sure you have the right MySQL drivers installed, THEN double-click...." You get the idea.

Most people have a hard enough time with "Copy the .mdb file to c:\dbprogram". Requiring them to install a service with appropriate drivers on their old PentiumII running Access2k is a nightmare and suicidal for a small software company.

Re:Try SQLite

[ttfkam]

It's not like you can just drop an *.mdb file onto a box and use it. Access still needs to be installed. This puts it on about equal footing with MS Access in that even though MS Access is more common, MySQL is a free download if the system you're on doesn't have it. Of course, that assumes your office is running MS Windows. (Not a bad assumption, but good to keep in mind.)

Along those lines, you shouldn't be coding directly to MS Access anyway. Writing your stuff to an ODBC datasource is a much better choice. Luckily, every popular database in existance has an ODBC driver. With ODBC (or ADO) and a client-server database, you can have the database local to you for initial development and then move it off to a dedicated server without changing a single line of code. With a MS Access database, you can have a dedicated fileserver, but locking issues between clients get really hairy after more than a couple of people connect and work at the same time.

SQLite is great if memory constraints are very tight and you probably won't move to a client-server model in the future. How much is a 256MB DIMM these days? 256MB is enough for most relational databases to have a field day with the datasets that MS Access is used to. And memory's only getting cheaper. Make sure that you have a real need to constrain yourself to the in-process model before jumping in.

Also note that if you use an ODBC datasource, you can use the comparatively wonderful Access frontend and have a real data store in the background doing the heavy lifting.

But then, if you really wanted to do it right, you'd use something better than MySQL on that backend like MaxDB, Firebird, or PostgreSQL; Same cost, more features, scale better with concurrent writes, and safer for your data (actually tells you when crap data is trying to find its way in) than MySQL. Remember, if you're talking about replacing MS Access, you're probably not talking about a web environment anymore. Chances are that it's not 99% reads.

Or... Revolution

[Anonymous Coward]

Check it out: www.runrev.com.
Windows, Linux, MacOS 9/X.
Looks much nicer than GTK or Java.
Much easier to script.
MySQL, Postgres, OpenBase, Oracle, ODBC, etc.
Also works with Valentina- a pretty darn fast Mac & Windows embedded database engine.

It's not for everything, but if you want cross-platform RAD, it should be in your bag of tricks.

Re:Try SQLite

[man_of_mr_e]

Everything that you said is true, but MSJET doesn't run as a service. It's just DLL's that get loaded into the applications process space and execute in the context of the application.

Use Access as a GUI for mySQL!

[Mr. Cancelled]

For a content management system I've developed, I prototyped all of the basic functionality by using Access as a GUI for mySQL. And I loved it! I actually considered doing the whole thing this way for a bit as it offered so many of Access's strengths (quick and powerful GUI building, familiar environment, everyone has it, etc.), but was combined with mySQL's stability, scalability (Well... For the needs of my target audience at least), and versatility. All's you need to tinker with this is the free MyODBC [mysql.com] package, and suddenly your mySQL database is seen as a standard ODBC one. You can build table relationships within Access using mySQL based source data. You can locate the mySQL server anywhere you want (local or remote), point Access at it, and there ya go. Additionally you can now use VBA within Access to take advantage of many Active-X components, as well as a wealth of freely available VB code. There were several reasons I went back to my original plan of just prototyping in Access, and deploying via a web-based setup:

1. Obviously not everyone has Access. Many do, or have access to it via work or school (access to Access?!?)
2. There were certain things that were easier to implement in an HTML-based setting (conversely, there's things I still can't equal that were accomplished easily using VB & Active-X. Things such as a customized file browser with a built in image viewer)
3. While some of my VB code and Active-X'ing would have been transferable to the web, it would have required requiring that the user of my system use IE to administer it. Not gonna happen!
4. I just don't like Microsoft enough to make my product only available to users of their software. The above IE example would have required my admins to IE; Access would require users to have Access; Having Access implies that the user must also run Windows (Wine just isn't there for Access usage I'm afraid. At least not for very advanced usage)

But for other projects I have, who's target audience is Windows users, Access is a great way to quickly build some impressive mySQL-based applications. IMHO, of course. 8)=

Re:Try SQLite

[man_of_mr_e]

Not exactly true. While it's true that the service won't use many (if any) CPU cycles while waiting, it will use memory.

You're incorrect that this memory will get swapped to disk, since that will only happen if memory becomes low.

The problem with this is that Linux (as do many OS's) has a system of buffers and caches which use unallocated memory to speed up the OS. Having a bunch of memory allocated (but not enough to swap them out to disk) lowers the number of buffers and caches available to the OS, thus decreasing performance.

Finally, whether or not the memory is swapped out to disk, it's still resources, and it's still wasting them if the service isn't being used.

Almost right

[ttfkam]

So there still isn't a production-quality MySQL server.

Re:Try SQLite

[Narcissus]

MySQL Connector/C++ (the C++ API from MySQL) is LGPL.

So long as you link it correctly, you do not need to release the source code to your application: no matter how confusing the licencing on the MySQL website is...

postgresql syntax conventions? LOL

[kpharmer]

ok, so postgresql has two issues with syntax, and mysql has dozens of situations in which it will silently fail.

And that's comparable?

If you want to read something amazing, go ahead and read the MySQL manuals, look for design deficiencies: http://www.mysql.com/documentation/mysql/bychapter /manual_Introduction.html#Bugs

You'll see more than just minor syntax issues - you'll see that mysql spends most of its time in silent error mode.