Slashdot Mirror
Core Web Application Development with PHP & MySQL
jsuda writes "Core Web Application Development with PHP and MySQL is an intermediate
to advanced-level guide for programmers and developers. It bills itself as >everything
one needs to know about building robust database applications. That is a
bit of puffery but this is a comprehensive practical guide for designing and building
production-quality, database-enabled applications." Read the rest of John's review.
Core Web Application Development with PHP & MySQL
author
Marc Wandschneider
pages
912
publisher
Pearson Education
rating
8
reviewer
John Suda
ISBN
0131867164
summary
Fine strategic overview
The author is an open-source platform expert and software developer. He comes from a background of working with standard desktop Windows-based applications and made the transition to building dynamic web applications. His experience in making the transition informs this book as a comprehensive explanation of how to use the various technologies that go into writing web applications. For those making similar transitions, this is a very fine presentation done by a thoughtful, systematic designer. For those already busy in the PHP/MySQL area, the advanced level of instruction is likely to be valuable.
The emphasis is on open-source applications, particularly PHP5 and MySQL in an XHTML/Javascript environment. But, beyond technologies, the author's focus is on the strategies and systematic approach one needs to design and implement successful web applications. He writes for an advanced audience which is already basically familiar with programming and XHTML. Those writing or planning dynamic web applications will benefit most from the book.
There are 33 chapters in five parts - basics of PHP, database basics, planning web applications, implementation, and sample projects. There are three appendices covering installation and configuration of PHP, MySQL, and other related open-source applications like Apache, a set of charts of database function equivalents among the leading database types - MySQL, Oracle, PostgreSQL, Microsoft SQL Server, and a short list of recommended reading.
This is a large format book of 912 pages, including index. My reviewer's copy is a prepublication version containing grayscale graphics and much white space, especially around the code snippets, making reading easy and comfortable. Although the material is high-level and technical, the writing seems light and casual. Wandschneider's writing style flows easily, never bogs down even with technical details, and the book reads much faster than one might expect.
Although the best part of the book contains the three start-to-finish sample projects at the end - a calendar system, weblog engine, and e-commerce store, the lead-in chapters are nicely done, too. Chapters 1 and 2 are about getting started in PHP. There is a brief comparison to perl and C++, but the bulk is about PHP terminology and programming concepts. Much is made of PHP5's new object-oriented features, but the discussions of that here (and in Chapter 4) was about the only parts which I feel needed more clarity - the rest of the chapters are very clearly stated and contain plenty of good examples.
Chapters 3 - 7 continue with scripting concepts like functions, classes, arrays, strings and characters. The discussion is not designed to instruct comprehensively about PHP itself but works on a higher level of showing how PHP interacts with MySQL and other technologies on an overall basis. You can get detailed PHP coding instructions elsewhere. Chapter 6 contains an unusually good discussion of character sets, usable for global applications, and provides instructions on configuring Unicode and multi-byte support for high-level applications.
Part 2, Chapters 8 - 12, take the same approach to MySQL and databases in general. They include discussion of basic terminology and concepts, designing and creating databases, storing and retrieving data, PHP-to-database connectivity, and advanced topics, like use of "transactions" and advanced querying.
Part 3, Chapters 13 - 17, deal with the server-side matters. Again, the level of presentation is not on comprehensive details of PHP, MySQL, and web services, but present a comprehensive overview to guide planning, design, and implementation. Here the author states overall design considerations of a website noting how to incorporate CSS, HTML, code libraries, user interfaces, and web services into a working dynamic website.
User management and security concerns are noted throughout the book and Chapters 14 - 17 deal specifically with validation, and software and hardware security, including tips on how to secure your server. These passages on security are some of the better and clearest written I've experienced in this area.
Part IV continues the systematic approach to website construction discussing error handling, debugging, cookies, and sessions (again some of the clearest explanations I've read), authorization, and data validation with regular expressions. Chapter 21 is entirely about globalization and localization that is, dealing with the fact that the Internet is global and that there is a need to deal with foreign language sets. There are tips on how to determine users' locations and how to script to account for different language sets, including Unicode.
Chapters 23 and 27 are about XML and are especially useful now that XML and XHTML are becoming the reigning protocols of dynamic web activity. There is an extensive sample of using XML to work with the Google API. Using XML with PHP is an advanced topic and it is only generally covered here, together with XML web services and SOAP. Other chapters cover the use of extensions to PHP, like PEAR, developing a coding "style", creating test suites, configuring PHP.ini, and more. The three working examples are extensively commented and contain complete code examples.
The book comes with a comparison CD-ROM containing all of the sample code, and versions of PHP5, MySQL, and Apache HTTP server."
You can purchase Core Web Application Development with Php & MySQL from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
The author is an open-source platform expert and software developer. He comes from a background of working with standard desktop Windows-based applications and made the transition to building dynamic web applications. His experience in making the transition informs this book as a comprehensive explanation of how to use the various technologies that go into writing web applications. For those making similar transitions, this is a very fine presentation done by a thoughtful, systematic designer. For those already busy in the PHP/MySQL area, the advanced level of instruction is likely to be valuable.
The emphasis is on open-source applications, particularly PHP5 and MySQL in an XHTML/Javascript environment. But, beyond technologies, the author's focus is on the strategies and systematic approach one needs to design and implement successful web applications. He writes for an advanced audience which is already basically familiar with programming and XHTML. Those writing or planning dynamic web applications will benefit most from the book.
There are 33 chapters in five parts - basics of PHP, database basics, planning web applications, implementation, and sample projects. There are three appendices covering installation and configuration of PHP, MySQL, and other related open-source applications like Apache, a set of charts of database function equivalents among the leading database types - MySQL, Oracle, PostgreSQL, Microsoft SQL Server, and a short list of recommended reading.
This is a large format book of 912 pages, including index. My reviewer's copy is a prepublication version containing grayscale graphics and much white space, especially around the code snippets, making reading easy and comfortable. Although the material is high-level and technical, the writing seems light and casual. Wandschneider's writing style flows easily, never bogs down even with technical details, and the book reads much faster than one might expect.
Although the best part of the book contains the three start-to-finish sample projects at the end - a calendar system, weblog engine, and e-commerce store, the lead-in chapters are nicely done, too. Chapters 1 and 2 are about getting started in PHP. There is a brief comparison to perl and C++, but the bulk is about PHP terminology and programming concepts. Much is made of PHP5's new object-oriented features, but the discussions of that here (and in Chapter 4) was about the only parts which I feel needed more clarity - the rest of the chapters are very clearly stated and contain plenty of good examples.
Chapters 3 - 7 continue with scripting concepts like functions, classes, arrays, strings and characters. The discussion is not designed to instruct comprehensively about PHP itself but works on a higher level of showing how PHP interacts with MySQL and other technologies on an overall basis. You can get detailed PHP coding instructions elsewhere. Chapter 6 contains an unusually good discussion of character sets, usable for global applications, and provides instructions on configuring Unicode and multi-byte support for high-level applications.
Part 2, Chapters 8 - 12, take the same approach to MySQL and databases in general. They include discussion of basic terminology and concepts, designing and creating databases, storing and retrieving data, PHP-to-database connectivity, and advanced topics, like use of "transactions" and advanced querying.
Part 3, Chapters 13 - 17, deal with the server-side matters. Again, the level of presentation is not on comprehensive details of PHP, MySQL, and web services, but present a comprehensive overview to guide planning, design, and implementation. Here the author states overall design considerations of a website noting how to incorporate CSS, HTML, code libraries, user interfaces, and web services into a working dynamic website.
User management and security concerns are noted throughout the book and Chapters 14 - 17 deal specifically with validation, and software and hardware security, including tips on how to secure your server. These passages on security are some of the better and clearest written I've experienced in this area.
Part IV continues the systematic approach to website construction discussing error handling, debugging, cookies, and sessions (again some of the clearest explanations I've read), authorization, and data validation with regular expressions. Chapter 21 is entirely about globalization and localization that is, dealing with the fact that the Internet is global and that there is a need to deal with foreign language sets. There are tips on how to determine users' locations and how to script to account for different language sets, including Unicode.
Chapters 23 and 27 are about XML and are especially useful now that XML and XHTML are becoming the reigning protocols of dynamic web activity. There is an extensive sample of using XML to work with the Google API. Using XML with PHP is an advanced topic and it is only generally covered here, together with XML web services and SOAP. Other chapters cover the use of extensions to PHP, like PEAR, developing a coding "style", creating test suites, configuring PHP.ini, and more. The three working examples are extensively commented and contain complete code examples.
The book comes with a comparison CD-ROM containing all of the sample code, and versions of PHP5, MySQL, and Apache HTTP server."
You can purchase Core Web Application Development with Php & MySQL from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
Must take up a lot of shelf space.
An honest question for anybody to answer. Do most people still learn by picking up a 900+ page book rather than learning from example? I find most technical books extremely difficult to finish so I very rarely attempt to read them.
bluespaceradio.com - New Wave, Indie and Alternative
Does anyone know of a good debugger for PHP applications? I'd like to be able to step through the execution of a php script...
I can't understand how a book which (according to the review) doesn't have a chapter dedicated to the concept of "multi-tier programming", can have the presumption to say it's '>everything you need'. Heck, it doesn't even MENTION templates.
As some of you know, multi-tier applications have (at least) 3 tiers: Database, business-logic, and interface. Java guys know this better: Model-View-Controller.
I have implemented for my webapps an MVC framework, and maintaining them or modifying them is a piece of cake. It's so easy i get bored with it sometimes.
In comparison, recently I've had to adapt the OSCommerce 2.2MS2 (built in PHP) for one of our clients' store. Every single php file in it has database, business-logic and interface ALL MIXED. The only separation they have is wrappers around SQL functions (that's not true separation, but a mockery). Maintaining it is a LIVING NIGHTMARE.
So please do yourselves a favor: Study the MVC approach and implement an MVC framework in PHP. You can use any templating library you can find. (for database, i use an adapted version of phplib's sql library). This alone has saved me not hours, but weeks of work, and is worth ">everything" you could learn from that book.
Bringing MySQL compatibility to PostgreSQL
Oh phooey.
MySQL is fine for the vast majority of applications out there. You can build robust database applications with it, no problem. Now, if what you are really trying to say is that there's better things out there, then sure I'll agree with you. But to just say that you can't get robustness out of MySQL... I don't think that's accurate at all.
Ebay changes their site, a week before Christmas. These people are stupid. These people are astoundingly stupid. If you looked up STUPID in the dictionary it wouldn't have the eBay logo, but direct you to an encyclopedia which has more space to go on about their profound acts of stupidity, when they've been stupid, how they've been stupid and how they've often failed to repeal their stupidity or even learn from it.
They aren't the only guilty ones. Less is More and too often I've had to deal with sites poorly constructed, as replacedments for sites which worked quite well.
Probably more along the lines of programing and some Gee-Whizzy things, but every web programming book should dedicate a chapter on when and how to make changes and common pitfalls to avoid.
A feeling of having made the same mistake before: Deja Foobar
No offense intended, but when I think "robust" I think of certain basic minimum requirements that MySQL is either lacking, or are in 1.0 release phase.
I don't respond to AC's.
Gnight writes
Hmm. Certainly looks like an informed opinion, but I wonder whether it could be from someone with a bias, perhaps?
Ah. There's the dead giveaway. Gnight is on the the MySQL Quality Assurance team.
Most of the MySQL using code I've seen out there doesn't use transactions, but instead just trusts that changes will be independent and take effect. Jumping to an ACID compliant (by default) database won't make a huge difference if you're not using proper transactions anyways. Although the better multi-join query performance may help.
> MySQL is fine for the vast majority of applications out there.
Ya, I've heard that line of bs from mysql for about a half-dozen years:
- they said it when they didn't have transactions - and it wasn't true
- they said it when they didn't have unions or subselects - and it wasn't true
- they said it when they didn't have referential integrity - and it wasn't true
- they said it when they didn't have triggers, stored procs, and views - and it wasn't true
Now, they've resolved *most* of the problems, and it's *almost* true. Sure, you can build robust applications with it. Of course, you can build robust applications with msql as well - it's just the extra effort that is required to achive "robustness" when:
- silent errors and data corruption problems current and historical
- frequent deviations from ansi sql (comments, nulls, etc)
- simple optimizer that is notorious for performance problems on 5+ way joins
- if you're planning on having your app run at various isps, most don't support current version - leaving you stuck historical issues (no views, etc)
- lack of parallelism or partitioning features - giving it about 2-5% of the speed of oracle/db2/informix when it comes to large table scans (reporting, analytics, etc)
So, sure. You can build robust apps with it. But man, it is so much more work than using postgresql. Let alone db2 or oracle. Maybe this makes sense for somebody (asp model targeting large number of isps) where you can afford the economics of re-inventing the wheel since most isps are running back-level versions.
Now, this might change in two years. Assuming that MySQL comes up with a substitute for Innodb (no attractive options yet), simplifies their licensing, and resolves the most significant existing issues. Then yes, it will be a reasonable option, right up there with postgesql, etc. Until then save your licensing dollars for something better and freer.
I guess someone is rehashing this review. If you stroll down the Amazon page for this book, you get the same review text found in this Slashdot article but dated 10/30/2005. So much for submitting an original review. Then again this is Slashdot.
You haven't used mysql in a while have you? You ought to give v. 5 a try.
"Core strategic web application paradigm development with AJAX, Synergistic go-to-market edition"
Why in the hell was this modded down as 'Troll'? Anyone who is vaguely familiar with database systems knows that mySQL is one of the more entry-level players out there. Sure for hosting a bunch of select statements it's great. But it's barely catching up with the competition by providing such _groundbreaking_ items such as record level locking, triggers, stored procs, etc. now or perhaps in an upcoming version. Plus there still are the infamous mySQL gotchas, many of which apply today as they did back in 1997 or so. Gimme a break, people!
It's not just programming, you should see the way that guy acts on gamefaqs. It's almost depressing.
For me, the database is the most important piece of our business. Absolutely mission critical. If a database goes down, nobody gets paid. I wouldn't even consider using any database version that is less then several years old. I'll let other people break it in and find all of the bugs and stability issues, first, before I trust my (and my employees') livelihoods to it.
I don't respond to AC's.
Books should be free.
They are free at the local Library.
He who knows best knows how little he knows. - Thomas Jefferson
The fact that you believe that implementing an MVC pattern to organize your UI layer
Oh please, Where did I say i used all that just to implement my UI layer?
Maybe if you paid enough attention to what I said, you'd have realized that I never implied "templates = multitier". Templates are a NECESSARY part of the view, but they alone don't make a multi-tier app.
To clarify, this is how i build my web-apps:
a) I have the main ".php" files which implement the Controller. Actually i use a prepend that includes them, but that's my approach. Each main php file has a function "handle_request()" which does all the processing. I came with this concept while studying Apache Velocity. The main php files include() the particular libraries used in the model, which is split between the business and data-tier.
b) Also, the prepend.php includes (engine.php), which itself include()s security.php. I call this is the "security tier" which lies on top of the controller. The security tier verifies that no weird requests are done, and filters the unnecessary global and environment variables. It also checks the login, session, etc.
c) For the database class I used, has two subclasses: one for reading the data, and another for writing. These can have two different users connected to the MySQL database. All database operations are done thru these classes, saving the app from SQL-injections in read-only queries. Also, having the controller embedded in a function saves us from global variables injection and other nastiness.
d) The controller arranges the GET and POST parameters into an associative array, which it passes to the appropriate business-tier function. In reality, I have the business and data-tier a little bit mixed, but it's organized enough that it doesn't give too much trouble.
e) The business-tier returns another set of parameters, which are to be passed (later) to the template (which template to use is calculated also based on GET and POST, even SESSION).
f) Finally, the controller returns in an associative array, the template file and the e) parameters to the engine.php, which uses a template object to process the output.
As you can see, while processing I do not use a single echo statement. All the data (database output) is passed thru associative arrays. In other frameworks, I'd have returned an XML string which would be passed to an XSLT engine.
So, I hope that's multi-tier enough for you. If you were so kind to show us how YOU implement your multi-tier apps (you didn't), I'd really appreciate it.
Having written a blog engine myself using PHP and MySQL and given it away as open source, I'm wondering what he calls "robust code" too... I'm a professional developer in the daytime, and no book code I have ever seen has been good enough for other people to pick up easily (not enough conventions etc).
If you're interested in my project by the way, head on over to the PluggedOut Blog project.
Jonathan Beckett http://www.pluggedout.com
Why? Because of maintenance. But templates are supposed to make it easier to maintain aren't they.
No. Templates are there to add another layer of complexity to an app. Seperating the html from the php so that the designers are not confused? Hire better designers. Easily allow you to modify the site?
Well yeah if you think changing the color is a modification that should be in the html (should be in css) then yeah.
Perhaps I only seen bad implementiations of templates but in my experience the end result was always that you could never tell wich part of the fucking site was controlling what and that even simple modifications meant you had to figure out the template engine being used.
In my experience sites either have tiny changes that can be done by the coder and designer working together in a good team OR should have been in css anyway. The big redesigns usually require a code change anyway.
Worse, I had to handle more then one site where the answer was simple, Oh you want that change, sorry no that can't be done in the template. Template changes is for cosmetic changes, not functionality changes. Most buyers of e-commerce sites just don't seem to realize it. They think template means you can change your website. Yeah, in the same way a skin can change your winamp/xmms.
Perhaps I just build my sites wrong, I tend to make the html and php far to intertwined with a lot of the html being build by the code not just the php filling in certain blanks.
Database abstraction is usually defended by how easy it makes it to switch databases without having to switch code.
Eh yeah right. How often does this happen anyway? Like the site redesign it just is not a frequent occurence. Worse you often find that in favor of abstraction they leave out nice handy features one database supports but nobody else. Mysql_return_id. Every handy and only done by Mysql.
Again perhaps it was just bad experience but I seen several cases where the abstraction layer used did not support this feature forcing me to code around it. Extra PHP code to handle stuff already in the engine. Oh I am happy now!
The company that insisted the most on the abstraction NEVER switched in the two years I was there. Extra code extra bugs for something that is never used.
Image this in the real world. Your car doors being welded shut because one day you might want to turn it into a race car. WTF?
What is my point? Well that theory and practice do not mix. Yeah I 3 tired apps are usefull sometimes BUT that does not mean every bloody application has to use it. Database abastraction is usefull for code that is certain to grow. 99% of websites do not. Templates are usefull when you know you will get a lot of requests for cosmetic changes that are to big to complex to fit into css.
As for the whole saving you hours of work deal. At how many hours cost? I once read a quote that went something like this, "Do not code for code re-use unless you know in advance you are going to re-use it at least 3 times. Else the time coding for re-use will simply not recovered".
It made a lot of sense.
Perhaps I am just allergic to buzzwords.
MMO Quests are like orgasms:
You may solo them, I prefer them in a group.
Save yourself $7 by buying the book here: Core Web Application Development with PHP & MySQL. And if you use the "secret" A9.com discount, you can save an extra 1.57%!
It seems to me that using database software only after it's several years old is extreme. I mean, that would mean you barely considered moving to SQL Server 2000 last year? I can see waiting maybe 3-4 months, at most a year, but several years? It sounds to me that if your database is that important, and backups of the data just aren't enough, then you need a less stressful line of work. Stop and smell the roses, and try out new products. They have this new Windows version now that has a green start button, instead of gray. It's crazy out there!
HighSchoolForever.com
The submitter of the review on amazon is "John A. Suda" and the submitter here is "jsuda" AND his amazon nickname is "jsuda1". I give it a 99.9999% probability that "John A. Suda" (aka "jsuda1") and "jsuda" are the one and the same. jsuda, here, just apparently decided to wait...almost two months before submitting it here.
Parent got it right on it not being exactly an original review, but at least Joe Bloe didn't (well, 0.0001%) submit John Suda's review.
:wq
Must be why everyone is using Postgess... OH WAIT! NOT!
MySQL is a perfectly fine set of APIs to wrap around flat files. And, since the majority of websites would get by just fine with flat files with very simple file-level locking, by extension the majority of websites would get by just fine with MySQL.
However, I don't think anyone with any knowledge uses MySQL as a database. The idea is absurd.
The text violated the Slashdot review guidelines: "If you've reviewed the book elsewhere anywhere besides a personal home page (for instance, on Amazon) please be sure that your review for Slashdot is substantially different."
You know, there are a lot of places using databases servers that haven't been restarted since mysql v. 2 was the latest and greatest.
The fact that every six months mysql comes out with a brand new, latest and greatest, we-honestly-got-it-right-this-time-for-real version doesn't give anyone warm fuzzies.
ou need a less stressful line of work.
That's what happens when you own a new, small business. *Everything* is absolutely, positively mission critical, with little to no room for error. We also stay one full calendar year behind releases for our point-of-sale software since, of course, if that goes flaky, I'm equally broke. Hell, I won't even use USB devices quite yet. All good, solid, parallel port and serial port connections for our important equipment.
If our database got corrupted, for example, we'd have to take time to shut down and restore from a backup, and try to fudge all of the missing data. Some super important data, like credit card transactions, would be lost, which means than $5K worth of lost transactions means $5K lost if we hadn't settled recently. A day or two down to deal with the headache would be many thousands in lost sales, and of course, pissed off customers that may or may not come back. And, we'd have employees twiddling their thumbs. It really *is* that important from my point of view.
I don't respond to AC's.
And with google's new technology, we won't even have to go the library!
PHP programming is becomming about the libraries. Smartyhttp://smarty.php.net/ - a template library makes putting coherent websites together easier. Although it doesn't do anything for the database part of the site, its one less thing to worry about.
e ator/reference/quicktour/2/flash/index.html
PEAR confused me and I was programming before it so I have my own libraries. The php web documentation is excellent.
although the java studio creator is now free, and seems like an amazing tool, its not enough to get me away from php
http://developers.sun.com/prodtech/javatools/jscr
A book on PHP and MySQL. I've been waiting for this for ages!
Really, this is just what we needed.
We suffer more in our imagination than in reality. - Seneca
and your that mind tries hard to make essentials for any project, and don't mind the drawbacks from one another
I'm positive, don't belive me look at my karma
More projects should be so lucky. MySQL has had a huge automated test suite for years.
how to invest, a novice's guide
Please expand on why Innodb is a valid reason to reject MySQL or even make it unattractive.
P.S.
For websites, MySQL still seems like a good choice. MySpace uses MySQL. I wonder what they would have to say?
Often wrong but never in doubt.
I am Jack9.
Everyone knows me.
Sounds like a moving target to me. No matter what mysql does (or doesn't do), it will never be "good enough", because elitists will always need something to bash. Even if it was just the postgresql codebase renamed. It would still "suck" because it's "mysql".
It's just a fashionable and trendy target to bash.
Sorta like the (open|free|net)bsd zealots who bash linux. They're so insecure in their choice of OS that they need to put down something else in order to feel better.
it was modded down as troll because it was a troll.
all this database elitism smacks of the old "my amiga is better than your atari" infantilism.
only those people so insecure in their choice of software would find a need to go out of their way to bash something else.
after all, everyone with an IQ greater than a glass of water knows both postgresql and mysql suck. oracle is the only real database in the entire universe.
why fudge any missing data, you do use transactions don't you? Somehow I'm not believing your story one bit it seems contrived!
> I'm also you don't like the licensing, but I'm not going to argue philosophy when I have the
;-) But, if you can commit to staying completely GPL you're probably fine. Not everybody can. Nor given the changes to their license in the past is there any guarantee that future inconvenient changes won't be made.
> practical experience of NEVER coming up against it, over the years. I use it as a tool, not
> as something to repackage and resell.
Well, somebody is coming up against it - it pays their bills, and the possibility of making this revenue is what got them their investment dollars.
> Please expand on why Innodb is a valid reason to reject MySQL or even make it unattractive.
Oracle now owns Innodb. They compete with mysql for low-end database revenue, and they certainly didn't buy it to do MySQL any favors. Their solution is to either increase licensing fees and gain revenue off mysql, to harm MySQL by GPLing Innodb, or just to undermine MySQL growth by injecting uncertainly into its future. There are other possibilities but none seem credible.
This is a very real threat, one that took the MySQL folks almost a month to even respond to directly. Sure, they can fork Innodb, but they lack the personnel & skills to pull that off. And there are no other comparable products for them to go to in the market.
Given that Innodb is where about 80% of the innovation and must-have capabilities within MySQL come from (transactions, foreign key constraints, etc) their future is seriously in question. Until this is resolved, I would not use this database for a new project unless my shop was already 100% commited to MySQL.
> For websites, MySQL still seems like a good choice. MySpace uses MySQL. I wonder what they would have to say?
I think it was a good choice three years ago, but not really since then. The thing about using mysql for your website is that you'll probably want some other product for other applications internally. And then what? You've got to now learn and support multiple database products. Given the cost of labor, that's generally not a great strategy. It's generally cheaper to stick with a single product.
I have to agree with many other in this thread, The idea that mySQL is not 'good enough' can be true in some cases, but it doesn't mean it's enough good for many of us. Sounds like an elitism to me, or atleast somewhat shortsighted view.
I've never been a MySQL fan, but I do use it at work where I develop and keep up a website. It doesn't cost anything directly to us(our webhost keeps it up), and it is far more than aduquote to most things one can come up with.
Maybe it's not a F1 car or latest Audi, but even if it is rusty old VM the cost/use ration is excellent if one just needs to move from point A to point B. Maybe it doesn't accelarate from 0-100 mph quickly enough, or maybe it doesn't have the latest GPS navigation system. But most of don't need them either. Not all business needs need the ultra hyper new database that can do EVERYTHING. Most of real life needs are just fetching the information and getting it to the webpage.
Infact I'd argue MySQL has more features that most people ever really need from a database. Outruling a case where one would become a de facto database expert.
Nobody knows the trouble I've seen, nobody knows has the trouble seen me, even I sometimes wonder why I write these line
If I have a database that is handling sales, and it crashes, gets corrupt, the machine dies, etc., transactions are irrelevant. I'm talking about sales transactions. Those, along with all shipping, receiving, etc. data since the last backup would all be lost. Of course all of our apps use transactions (in the database sense).
I don't respond to AC's.
The original claim, that "MySQL is fine for the vast majority of applications out there" is not invalidated by any of the problems you point out.
The objections you raise are valid, but irrelevant. There are far more cases of small-scale applications use out there than Industrial Strength applications. Who cares if some David Hasselhoff fan website's bulletin board isn't robust? Even the owner of the board probably doesn't REALLY care.
See also: http://www.dreamsongs.com/WorseIsBetter.html
How the hell can you ask for MySql to simplify the licensing issues? wtf?! here they are (as I understand them) in laymens terms: Are you a business? No. MySql is free, but you only have support from the other open source people around the world. Are you a business? Yes. MySql is free, but you pay for support for the program. How much simpler could it possibly get?
There, much better. :-)
Save yourself $7 by buying the book here: Core Web Application Development with PHP & MySQL. And if you use the "secret" A9.com discount, you can save an extra 1.57%!
Protect your browser with the Force Safe Search add-on
When I say that MySQL is fine for most applications, I mean now, not 6 years ago.
I'm glad we agree.
Ok, I guess I'll give you these. I'm just glad that PostgreSQL and all the others don't deviate at all from the ANSI SQL stantards.
Also, I have never had a problem with MySQL corrupting data. Do you have any references regarding data corruption due to a fault in the MySQL code? (seriously, I would like to read about it)
I would consider these advanced functions.
How is this MySQL's fault?
I'm not saying that MySQL is better or worse than anything else. What I'm saying is that for the vast majority of applications out there, MySQL will do the job just fine.
No, in two years people will still be dinging MySQL for its shortcomings instead of giving it credit (even just a little) where it's due.
MINUS: if i wanted to read the Table of Contents, I would go to google print or B&N - what a worthless review.
PLUS: I own this book. It's actually very good.
I can't answer all of your points (I don't know enough about MySQL), but
some are clearly no longer true:
> silent errors and data corruption problems current and historical
MySQL has an SQL_MODE of STRICT. Which changes the silent error behaviour.
MyISAM tables are fast, but can get corrupt if say, you lost power. If this poses a problem use InnoDB tables. Problem fixed.
> frequent deviations from ansi sql (comments, nulls, etc)
A lot more addressed in mysql 5 -- one of my big issues was trimming white space from strings.
> simple optimizer that is notorious for performance problems on 5+ way joins
This did occur when it took too long to work out an execution plan. There is now a greedy optimizer (automatically invoked in MySQL 5), which resolves most of these issues.
As for the whole saving you hours of work deal. At how many hours cost? I once read a quote that went something like this, "Do not code for code re-use unless you know in advance you are going to re-use it at least 3 times. Else the time coding for re-use will simply not recovered".
;-) )
:)
;-) Actually, I think we all are.
I use my framework in 5 different intranet developments (two for the same company), so yes, it has saved me a lot of time.
In fact, to start a new development, I just copy the code from the OTHER development and just erase the particular php / template files, and modify the config.php file. Ta-da.
I made the basic framework in about 3 weeks, in my previous job. I adapted it (and improved it) to my current job where I made my first development with.
About database abstraction, I agree with you. In my pre-previous job we had to stick to "standards" because our clients wanted to use Informix for later. Pfft... all the sql code was too generic and slow. Since at my current job we're using MySQL and not changing, I can use the proprietary features.
My templates are php-based (google for "Beyond the Template engine"). So the templates have mixed PHP and HTML, this is a very powerful approach, since it overcomes the "oh sorry that can't be done from the templates" limitation in most templating engines.
In fact, if I was ever forced into using (eeew) smarty or other template engines, I would stick my "php-templating" class and use smarty only for the cosmetic changes.
My modified class allows me to use sub-templates, so i have a "main" template (i.e. logged in / guest) for the main site look-and-feel, and a "body" template which deals with the web app.
In my development i often generate excel spreadsheets. So I can choose between an HTML and an EXCEL template. Since both of them are PHP-based, i have no problem, it's the same data. (I used PEAR spreadsheet class to generate the excel. Not what you'd expect from a "template", would you?
This is the true power of templates
Perhaps I am just allergic to buzzwords.
Yes, you are
I want what you're smoking.
Something seldom mentioned are all the limitations in oracle, like SQL query length limitation, table column name limitations, general select statement limitations ( try : select * from WHERE id IN ( <and list over 1000 here> ), etc.
As long as your doing relativly simple transaction heavy operations oracle might be sufficient, but the hidden limitations it contains make it a PITA for more advanced usage.
*sigh*
"He was a wise man who invented beer." - Plato
Right, and now you put your own associate tag in the link. What a fucking n00b.
Dude...STFU
> Sounds like a moving target to me. No matter what mysql does (or doesn't do), it will never be "good enough", because
> elitists will always need something to bash. Even if it was just the postgresql codebase renamed. It would still
> "suck" because it's "mysql".
nah, once the capability = the hype, then there will be other targets for scorn.
> Sorta like the (open|free|net)bsd zealots who bash linux. They're so insecure in their choice of OS
> that they need to put down something else in order to feel better.
nice, a faith-based argument in which facts don't matter - and even pointing to short-comings in a product just proves you're wrong.
Kind of like:
Brian: I'm not the Messiah! Will you please listen? I am not the Messiah, do you understand? Honestly!
Woman: Only the true Messiah denies His divinity!
Brian: What?! Well, what sort of chance does that give me? All right... I AM the Messiah!
Followers, en masse: He is! He is the Messiah!
If I have a database that is handling sales, and it crashes, gets corrupt, the machine dies, etc., transactions are irrelevant...
There are methods for keeping off-site transaction logs; even if your server catches on fire and burns you can come back up to last committed transaction. It's probably expensive, both in complexity and setup costs, but it might help you sleep a little better at night.
It was supposed to be a joke. I "fixed" the referral link. Then I went out on a limb and I included this new thing called a smilie...
:-)
...that all the cool, hip, and with-it kids are using to convey humor on the Internet. It's brand new, so you may not have heard about it yet.
Protect your browser with the Force Safe Search add-on
that was so far over your head it was in another galaxy.
> - silent errors and data corruption problems current and historical
After seven years of using MySQL on production systems, I don't see this as a problem at all. I know my db admins cringe when I say that, but all of my programmers agree. With web-based applications you always should check the validity of your input anyway for security reasons and to provide useful error messages back to the user. The users aren't doing their own SQL queries that update data any longer like they did a decade or more ago.
The two worst things MySQL silently changes are numbers that are too small or too large and invalid dates. If you're even half-way careful, it's never a problem, and you end-up with a better application in the end.
Another nice thing is that for many applications, you know better what you're doing than the database. A couple of our customers switched from a different SQL server because that server wouldn't allow them to put in dates like 2005-12-00. While that is an invalid date, it's amazingly useful for any date that needs to be between months or between years. For example, end of the year or end of the month entries in an accounting system. If you go to the end of the previous month they don't show-up and if you start on the current month they don't show-up. When you do a range that goes across the month end or year end, they show-up. I've worked on accounting systems for over 34 years, and I don't know of a better and more efficient way to do this. With MySQL, it just works.
Anyones choice of "programming" language (ahem...) aside, but I find it kind of silly that people are still building apps that use relational back end AND use XML (and that includes XHTML) to communicate with user agents. That's like "so nineties" :) Wouldn't it be a bit (or a lot?) more efficient (not to mention elegant) to store data in a native XML database?
And not have a single line of SQL in sight...
but your opening statement was about why you don't use current software, nothing in there mentions if the machine blows up old software will work better!
you give too much importance to a humble 'l'.
maybe freud can toy with this fact for a while.
>> - silent errors and data corruption problems current and historical
> After seven years of using MySQL on production systems, I don't see this as a problem at all. I know my db admins cringe when I say that,
> but all of my programmers agree. With web-based applications you always should check the validity of your input anyway for security reasons
> and to provide useful error messages back to the user. The users aren't doing their own SQL queries that update data any longer like they
> did a decade or more ago.
After nineteen years of using relational databases, I can tell you that unless you implement a systematic method for finding them, data corruption problems are incredibly difficult to find. I've *never* encountered a production database I couldn't find them in. And they vastly multiply in databases that doesn't support transactions and constraints! Believe me here, I spent years on the old & nasty solutions that preceeded the relational databases (Adabas - now maxdb, isam, vsam, IMS-DB, etc).
Application validation helps just a little - since it typically changes over time allowing different validations at different points in time. And it fails completely to protect you during data conversions, data cleanups, data migrations, major system upgrades, etc. To prevent these issues you really want a combination of database and application validations. In the database: transactions, enforced referential constraints, and enforced check constraints. In the application: input validations, complex business rules, etc.
You'll have some duplication, but it shouldn't be that bad. And you shouldn't have to protect everything from a database that will corrupt your data. Because you *will* screw it up. It doesn't matter how careful you are, there are too many places to screw up - especially with multiple people on a project that changes often.
> Another nice thing is that for many applications, you know better what you're doing than the database. A couple of our customers switched from
> a different SQL server because that server wouldn't allow them to put in dates like 2005-12-00. While that is an invalid date, it's amazingly
> useful for any date that needs to be between months or between years.
And totally breaks portability with other databases
And totally breaks compliance with ANSI SQL
And totally breaks SQL arthimetic (how do you handle trans_date - 15 days when the trans_date = '2005-12-00'?)
When you find yourself sometimes putting a date to the day and sometimes putting a date to the month in the same column you need to step back. Almost always you are guilty of overloading a column with two meanings: there will inevitably be diffeent business rules between the two kinds of dates. A better solution is break them up, use a time dimension (simple to use and way more powerful!).
Since most databases these days allow you to create your own types, you're free to create a timestamp_to_month type if you want - that doesn't have days, but still supports date arithmetic. You could also create timestamp_to_week for the same reason, but there are multiple ways of counting weeks (even ISO standards).
But a solution in which you create invalid dates in a timestamp is really just gaming the system. Eventually it will bite you.
Ah, those MySQL guys. Their website offers the "Top Ten Reasons to Use MySQL" but at the end of the day we have to ask: what about Codd's 12 rules?