MySQL: Building User Interfaces 266
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.
MySQL Feature Set (Score:4, Insightful)
Interesting Book (Score:5, Insightful)
I know, it's not an original idea, but it's interesting because the book was a nice, step by step guide to doing just this. For what it's worth, I enjoyed it.
On the other hand, I ended up spending time with XUL instead.
Silly comment (Score:3, Insightful)
Since when do people read computer books on the throne? I would think anybody who's interested in this book (yes, you two hiding at the back!) would be reading it in front of a computer, trying out the sample code to learn what's going on.
Re:Try SQLite (Score:3, Insightful)
MySQL on the other hand (which may consist of multiple binary files) has to run a daemon (i.e., server) to be accessed. Your application uses the MySQL driver to talk to the MySQL daemon, either through TCP/IP or a local socket.
This is why MySQL will *never* be a replacement for Access, despite what I often see on slashdot. You can fit a small Access database on a floppy. Conversely, you may need a full fledged DBA to run MySQL.
Yes but... (Score:2, Insightful)
Re:Try SQLite (Score:2, Insightful)
> I suppose the app could easily be written to start the server when it starts and shut the server down when it ends
True, but besides being sort of hokey, the requirement of having MySQL installed might not be ideal if your target audience isn't savvy enough to install it, or perhaps don't want extra, normally unnecessary, stuff on their computer. I guess it all depends on your needs and target audience.
Depends on perspective (Score:3, Insightful)
Re:Interesting Book (Score:2, Insightful)
Re:windows developers (Score:4, Insightful)
I know many retarded people that would be offended by that statement.
Seriously though, making sweeping statements like that just makes it obvious that you were never good enough for the high school debating team...
Re:Make sure you use MySQL version = 4.0 (Score:3, Insightful)
Re:Try SQLite (Score:2, Insightful)
That's true -- it would be more accurate to describe DBM as a replacment for Access, and MySQL or PostgreSQL as a replacement for SQL Server.
Access 2k? SQL Server 97? (Score:3, Insightful)
Re:windows developers (Score:3, Insightful)
Re:Try SQLite (Score:4, Insightful)
Well obviously, I too can do a text export of Access and gzip it as well! But that doesn't, uh, help the situation.
And an Access database in an MDB file is hardly standalone, you still need a machine running Access to get much use out of it.
Wrong. You don't need Access to create/update/use an Access database. The functionality it built into Windows (actually part of a bigger module called Jet).
Why does OSS love MySQL? (Score:4, Insightful)
Move? (Score:4, Insightful)
Very few Windows applications are written in 'C' these days so converting an existing application to use MySQL would be pretty painful. You should have a better reason to port your code then simply avoiding MS tools.
Perhaps the book is better suited for developers who wish to switch to Linux for future development.
Both are replacements for MS SQL Server (Score:4, Insightful)
Also, if you need advanced XML querying tools for your database, none of the open source RDBMSs can currently act as a reasonable drop-in replacement for MS SQL Server.
If you don't need any of those features (and especially haven't actually used any of them in existing code), then MySQL could be added to the list of open source RDBMSs that fit the requirements for your project.
Re:Access 2k? SQL Server 97? (Score:3, Insightful)
Re:Why does OSS love MySQL? (Score:5, Insightful)
Postgres is pretty good, but still (IMHO) not yet up to the level of a commercial RDBMS. If you want a full-featured free-as-in-beer datacenter grade database, use Sybase 11.0.3.3 [sybase.com]. It doesn't come with source, but come on now, how many MySQL zealots have ever even compiled from source, let alone modified something?
Re:Why does OSS love MySQL? (Score:2, Insightful)
For me, MySQL is not a deficient implementation of the Likes of Oracle, but a full-featured, modern way of accomplishing what DBM did.
Re:Both are replacements for MS SQL Server (Score:3, Insightful)
I have to agree here. I was using MSSQL the other day and was able to open an XML document inside a stored proc and query it like it was a table. All I could say was "Damn, that's pretty cool!"
I had been using the FOR XML EXPLICIT quite a bit for output, but didn't (until recently) need to read XML back into the database.
Re:Make sure you use MySQL version = 4.0 (Score:5, Insightful)
Example? Okay, whip out your MySQL client and type with me...
CREATE TABLE test (
id INT NOT NULL AUTO_INCREMENT PRIMARY_KEY,
num1 INT,
num2 INT NOT NULL,
num3 INT
price NUMERIC(4,2),
code VARCHAR(8),
);
INSERT INTO test VALUES (
0,
99999999999999,
NULL,
'A quick brown dolphin...',
21474.83,
'ABCDEFGHIJK'
);
"Query OK, 1 row affected"
Seems to me that the data was a collection of square pegs to round holes, but MySQL never even dropped a warning.
So let's check out that table again:
SELECT * FROM test;
1 row with the following is returned.
id: 1
num1: 2147483647
num2: 0
num3: 0
price: 999.99
code: ABCDEFGH
Now stop. Take another look at the table definition. Take another look at the inserted data. Take another look at the output. Take another look at what has been stored in your database. Let's sum up: your primary key (your lookup key!) is not what you expected, the numbers are all different from what you entered, the price does not conform to your data schema (should be a maximum of 99.99), and your character string has been truncated...ALL WITHOUT AN ERROR OR WARNING.
More examples at MySQL Gotchas [sql-info.de]. All of this in MySQL v4.0 and above. None of this crap happens in Firebird 1.5, PostgreSQL 7.x, or any popular closed source relational database.
And yes, there's a PostgreSQL Gotchas page [sql-info.de]. Tables are lowercase by default, and it requires the "AS" keyword for column aliases. Look at that list for PostgreSQL. Look at that above example. Can someone say with a straight face that these lists are comparable? Can someone say with a straight face that they want to explain to the computer-phobe why they got 2147483647 in their data? Can someone say with a straight face to their boss that these errors are acceptable in a production environment?
Re:Try SQLite (Score:3, Insightful)
At smaller numbers (one or two hundred), who cares? Your server isn't using 100% of your resources (CPU or otherwise). They are just going to waste if there's no RDBMS loaded.
This argument is old. It's like the assembly vs. C debates in the seventies.
Re:Locking Problem (Score:3, Insightful)
I don't see this as a problem, because at least I see SQLite as more of a portable pre-packaged data structure, rather than a traditional multi-user database. I haven't had a chance to use it yet myself, but I look forward to using it in stand-along applications where I need good data structure and the ability to filter and search for specific data. I'm a fair hand with MySQL, so having all of this wrapped up into a SQL-compatible package is exactly what I need.
It means I get to concentrate on what I find more exciting about programming -- rather then spend a load of my time on file structure and data processing.
Re:Make sure you use MySQL version = 4.0 (Score:2, Insightful)
I do database work with MySQL and SQL Server 2000. All functions I write check that the data I'm getting or putting to the database matches the data type. It's a little extra legwork, but I don't carry a pager for dumb mistakes that can be avoided either.
Never throw data at your DB like as parent poster describes above.
I am in awe (Score:3, Insightful)
INSERT INTO test
(id, num1, num2, num3, price, code)
VALUES (
0,
99999999999999,
NULL,
'A quick brown dolphin...',
21474.83,
'ABCDEFGHIJK'
);
Now the syntax should be kosher.
And I applaud you for that. It's good to know that you never make mistakes, are always fully rested, are never up against a hard deadline, etc. I'm not questioning your coding skills or your intelligence. On the contrary, I think that extra checks are always worth it. What I am saying is that the database, the final repository for your data, should be making at least the same amount of effort.
When the string 'A quick brown dolphin...' is passed to an integer field because I'm overly tired, a collegue hasn't been as rigorous as I usually am, some crack-smoking intern had a brain fart, or whatever, the fact remains that MySQL detected that it wasn't an integer. It didn't try to throw it in as the first 32-bits of the binary string. The table needed a number, MySQL had no idea what number you meant, and it decided to put in the default value for the column according to its datatype. In other words, it placed a value that I didn't explicitly specify through the client or schema and did not warn the client that it had done so.
Imagine if all of those POSIX networking functions didn't return an error code. Why not? I'm sure there are folks out there who will say, "But my network is always up, the cables are of highest quality, and in all the time I've worked there, I have never had a socket connection fail; so why do I need the error code back?" No matter the preparation, no matter the training, no matter how good the conditions are, when the rubber hits the road, I would like to be able to see out of the windshield to see if I've spun out.
This is the salient point that people (including the pager-adorned gentleman in the parent post) appear to blithely ignore. It's the giant pink elephant in the corner that everyone notices but no one wants to talk about.
By all means, perform the extra checks. Perform a check at compile time, at deploy time, and at runtime. Why are MySQL folks so averse to having a check at insert/update time as well? Why is it such an affront to want your database to do its own data integrity checks? Why is it so horrible to expect a relational database to do its job!? I honestly want to know. I would very much like some insight into this rather than picking on my choice of salad fork.