Slashdot Mirror

As a professional PHP developer, I've found Web Application Development with PHP 4.0 to be one of the best books I've ever purchased. The authors, Tobias Ratschiller and Till Gerken, don't spens time and paper reprinting the manual. instead, they discuss the abstract concepts that distinguish a well-written webapp from a poorly-written one.

Coding conventions, organizing libraries, API design, and programming in a team environment are all discussed in depth. They include case studies and real-life examples of the concepts they cover.

To summarize, if you want a great discussion of PHP development that you *can't* get from the online manual, check this one out.

Maybe this is why MySQL isn't as popular for database(for things other then a website)?

If you are a real DBA, then having to use a SQL console or command line tools to administrate a database shouldn't be a problem. If you need to point and click to make a backup or create tables because SQL is too hard, then there is no way you can be a DBA. Besides, there is a good web based GUI, phpMyAdmin, that lets you do most things without knowing everything about SQL. There are also GUI interfaces to MySQL.

Also, PHP more popular then ASP? Possibly. But name anyone who makes money running a huge website (Slashdot excluded, they don't make money) with MySQL. There may be some, but anyone who is doing serious business isn't going to be using MySQL.

That's complete FUD. Say, do you work for Microsoft or Oracle? I can say first hand that directNIC.com uses MySQL for everything. They are a very popular domain registrar (sold over half a million domains) and are certainly making money. Many other companies use MySQL and not just for running websites. You should rethink your myths.

Fantastic is such a subjective word. Let's just say they are good.

In that past I've used Access to prototype, then exportsql (in the Mysql contrib page - it's too slow get grab a link right now) to create the script for mysql.
Now I generally use PHPMyAdmin to do it through the web.

Only Americans are stupid enough to use PHP, eh? That's funny, I know more European PHP users than American ones. Not to mention how many members of the PHP Group are European.

And then of course, there's the proliferation of PHP sites in Europe.

Yep, but that's Murphy's fault. The knowledge repository application can be found at the Errata page of the book.

Anyway, thanks for your support, and you can get more information about this book at http://phpWizard.net RSN.

I use MySql, and for a while now I've been using a very nice database utility called phpMyAdmin. It runs on PHP. It was created by someone in Italy, I think, and is available from www.phpwizard.net. It has worked great for my needs, providing a convenient web-based interface for creating, modifying, and dropping tables, inserting records, and running SQL queries.


At the moment, though, it is only available for MySql and PostgreSQL as far as I know. But since you it comes as PHP source code, and PHP supports Oracle, you should be able to get it to work without too much difficulty. Of course, you would need to write your own code to support the more advanced Oracle features (like foreign keys) that MySQL doesn't have. But if you do decide to build your own interface, I would recommend this as a good place to start.

Although I don't have any hard data to either confirm or deny your statement, I will accept as fact that Postgres has better performance on really large databases.

To me that's not a relevant selling point, while MySQL's speed is. I'm using PHP and MySQL to automate my company's intranet - content management, remote publishing, workflow, that sort of thing. The quantity of data that needs to reside in a database is relatively modest, so Postgres' superior performance at the high end is a benefit that I will never see. Our "Current Clients" or "Job Openings" databases just aren't going to get so big that MySQL strains under the load.

>But for real databases of actual size...

These are real databases, because they are storing real corporate information, reducing duplication of data, improving consistency, and generally making my fellow employees' work days better. Their actual size is very modest - much smaller than their actual benefit. Different tasks require different tools.

MySQL's speed does represent an immediate benefit to me, and to my users. Also, because I'm automating workflow, rather than handling financial transactions, I don't miss the features like commits or rollbacks that MySQL leaves out (specifically to increase the db's speed).

But the real "killer app" for me is the web-based interface to MySQL, phpMyAdmin. This is a truly wonderful utility which has saved me tons of development time. The basic interface permits me to administer MySQL from my browser, and I can crank out customized interfaces on very short notice, just by copying the php scripts to a new directory and commenting out the HTML that produces functions that I don't want to offer to the user. In a relatively "high trust" environment like the company's intranet, MySQL, PHP, and phpMyAdmin have made my job MUCH easier.

FYI, the makers of phpMyAdmin now have a postgresMyAdmin , too, although I've been so happy with MySQL that I don't feel compelled to change.

Although I don't have any hard data to either confirm or deny your statement, I will accept as fact that Postgres has better performance on really large databases.

To me that's not a relevant selling point, while MySQL's speed is. I'm using PHP and MySQL to automate my company's intranet - content management, remote publishing, workflow, that sort of thing. The quantity of data that needs to reside in a database is relatively modest, so Postgres' superior performance at the high end is a benefit that I will never see. Our "Current Clients" or "Job Openings" databases just aren't going to get so big that MySQL strains under the load.

>But for real databases of actual size...

These are real databases, because they are storing real corporate information, reducing duplication of data, improving consistency, and generally making my fellow employees' work days better. Their actual size is very modest - much smaller than their actual benefit. Different tasks require different tools.

MySQL's speed does represent an immediate benefit to me, and to my users. Also, because I'm automating workflow, rather than handling financial transactions, I don't miss the features like commits or rollbacks that MySQL leaves out (specifically to increase the db's speed).

But the real "killer app" for me is the web-based interface to MySQL, phpMyAdmin. This is a truly wonderful utility which has saved me tons of development time. The basic interface permits me to administer MySQL from my browser, and I can crank out customized interfaces on very short notice, just by copying the php scripts to a new directory and commenting out the HTML that produces functions that I don't want to offer to the user. In a relatively "high trust" environment like the company's intranet, MySQL, PHP, and phpMyAdmin have made my job MUCH easier.

FYI, the makers of phpMyAdmin now have a postgresMyAdmin , too, although I've been so happy with MySQL that I don't feel compelled to change.