Build a Database Driven Site -- Quick 251
| Build Your Own Database Driven Website Using PHP & MySQL | |
| author | Kevin Yank |
| pages | 359 |
| publisher | Sitepoint |
| rating | 8 |
| reviewer | Mary Norbury-Glaser |
| ISBN | 0975240218 |
| summary | Using PHP and MySQL to Build Your First Data Driven Website |
Yank starts with the basics of MySQL and PHP installation on Windows, Linux and Mac OS X systems (he notes PHP 4.3 differences as well), and walks the reader through his first PHP script (no, not "Hello World!"). This first chapter is well written, with step-by-step instructions and shell script examples. It will help even a newbie feel comfortable with the process, and encourage him or her to move on to the rest of the book.
Chapter 2 focuses on relational databases and SQL queries. This chapter is not an in-depth study of RDBMs, but rather an extremely brief overview of the concepts involved in order to introduce the reader to command line interaction with MySQL. A simple database is begun that will be used in later chapters.
Basic syntax and commands of PHP are covered in Chapter 3 (statements, variables, operators). There are a lot of simple examples here that clearly demonstrate the elemental concepts of PHP. Yank uses forms, user interaction and control structures (if-else, while loop, for loop) to illustrate some easy methods of data access and user interaction with PHP.
Chapter 4 combines the two previous chapters' concepts into the beginnings of a working data-driven Web site. Yank shows the reader how to use PHP to connect to a sample MySQL joke database ("A man walks into a bar....Ouch."). He introduces sending SQL queries with PHP (mysql_query, delete, insert, update), handling SELECT result sets and inserting data into the sample ijdb (Internet Joke) database.
Chapter 5 is devoted to relational database design, and expands the one-to-one relationship to many-to-one, one-to-many and many-to-many relationships, this chapter teaches the reader how to join data spread between tables into one resultant set. This chapter is not meant to deal comprehensively with the complexities of relational database design. Indeed, the author gives an extremely brief nod to the inherent informality of his approach and references other resources for deeper study. Yank's intention here, as with the entire book, is to use relevant real-world examples to illustrate the simpler types of relationships a beginner will experiment with and how to deal with complex data and table issues with good design practice.
The next chapter presents content management and restricted-access database administration without relying on the command line (a few hints on protecting pages with appropriate access restrictions are in the introduction to this chapter but aren't dealt with in any depth until Chapter 12). Chapter 4's mention of forms is revisited here, and forms are used to manage, add, search for, edit and delete data.
At this point, the reader will have designed a database, organized the data into categories, created Web pages to display the data to site visitors, and prepared pages for administration of the data. The HTML is separate from the data, thereby relieving the Webmaster from the onerous and constant task of having to refresh pages with content. Here, in Chapter 7, the reader learns to format and submit content without resorting to hand-written HTML by using PHP functions (Yank covers the more standardized POSIX regular expressions, not PCRE). Code examples for string replacement, boldface and italic text, paragraphs, hyperlinks and splitting text into pages are included. The last bit of this chapter is dedicated to automatic content submission and has a nice design note about creating a visible column to the joke table where newly submitted jokes are handled as a No value, which allows review by a content manager before being posted.
This leads well into Chapter 8, "MySQL Administration (backing up, access control, checking and repairing data files)." Yank explains mysqldump and the use of update logs to create a practical backup-management scheme. He also covers using the myisamchk utility to check and repair MySQL data files. Basic MySQL access control using GRANT (creates new users, assigns passwords and adds user privileges) and REVOKE (the reverse of those functions) is included in this chapter as well, along with some tips and tricks to prevent access control problems.
Chapter 9 "gets back to the fun stuff" with Advanced SQL Queries (sorting and GROUPing SELECT results, setting LIMITs, LOCKing TABLES, aliases, LEFT JOINs and Limiting results with HAVING) giving the reader a well rounded sense of the versatility and scope of SQL in general and the SELECT command in particular.
Yank veers from textual data in Chapter 10, "Binary Data" (image files, encryption keys, programs for download) and shows the reader how to deal with working with files in PHP, handling uploaded files in PHP, storing and retrieving binary data in MySQL and learning when to use semi-dynamic pages to lighten the load on server performance in the process.
Chapter 11 deals with creating persistent variables, and offers an excellent description of cookies and sessions in PHP. I like Yank's figure "the life cycle of a cookie," which shows a graphical representation of a PHP-generated cookie. Yank rounds out the chapter with a simple shopping-cart example that consists of PHP scripts handling a product catalog and a checkout page (very real world).
The final chapter of the book is titled "Structured PHP Programming," and focuses on techniques for organizing code in order to simplify management (using include files, writing your own functions and streamlining code within Web pages). Yank gives a lot of sensible advice here, and his approach is not preachy. He brings up many important pitfalls that developers fall into: too much code, difficulty of finding what you need, understanding how it works. As this is a beginner's book, I would say that good design, good technique and good sense go a long way and should be stressed at the start of anyone's career in coding.
Build Your Own Database Driven Website Using PHP & MySQL, 3rd Edition runs only about 350 pages with a clean, easy-to-read page design, comfortable typography, lots of script boxes and screen shots. The appendices cover MySQL syntax, functions and column types and PHP functions for working with MySQL. Errata can be found at sitepoint's Web site, and I can't stress enough the value of checking these out before delving into any technical or instructional book: the frustration level goes way down if you know in advance that there's a typo, or a step missing!
This is a beginner's book with the essential tools and techniques that will get anyone started with serving up their first dynamic Web site. The tutorial approach of this book makes it easy for any reader to follow the step by step instructions. Yank manages to cover pretty much every topic necessary to provide the reader with a clean overview of the topic. It's a quick read and gives the reader encouragement and enough knowledge to move on to more complex volumes on the subject. This book provides a great first step for the beginner."
You can purchase Build Your Own Database Driven Website Using 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.
quicker to roll your own vs. pre-made (Score:2, Interesting)
Database vs. XML Text Files (Score:2, Interesting)
The good ol' days (Score:3, Interesting)
The Web seemed to ruin this trend. CRUD screens via web forms is a pain in the glutious. Web standards were optimized for e-brochures, not business forms. Frameworks exist, but I have not found any that scale well in customization: if you need something outside of the framework, you are hosed.
I wish the OSS community would work on producing more CRUD tools. If we have to toss HTML+DOM+JavaScript to get it, so be it. I think a remote-GUI protocol workable over HTTP is possible.
Business development is so much smoother if you have good CRUD tools. Otherwise you spend all day reinventing the wheel and dealing with low-level annoyances. I know many slashdotters don't like dealing with CRUD issues, finding it boring or feel it lacks geek status or whatever, but there is a big business need for it. I am kind of a connoisseur of CRUD technologies (for good or bad), and the current wine is bitter.
Why MySQL and not PostGreSQL? (honest question!) (Score:5, Interesting)
Someone said to me that it's simpler, but from the little that I tried they seemed to have pretty much the same complexity.
Does it cover appropriateness to task? (Score:4, Interesting)
I can't help but feel a lot of 'live instant all the time' sites would be a lot more efficient if it was 4 database calls a day, rather than Every Single Time Slashdot Hits Their Site.
Watch your server go up in flames, QUICK! (Score:5, Interesting)
Unless you have a limitless supply of CPUs+RAM, you're going to need connection pooling very, very quickly. Frankly, they're so easy to use, I don't understand why anyone would bother coding a database app without them.
But, for a beginner, this seems to cover some of the more important structural aspects of RDBMS in relation to webapps, not just "look, ma, it's dynamic!" Most of the books out there I've seen seem to just assume you know what you're doing on the SQL side of things and just focus on the PHP/JSP/Whatever side of things, which is just a death sentence for a beginner who has never touched a SQL server...
What PHP really needs (Score:4, Interesting)
Then again, I suppose working namespace support is probably a more pressing concern at this point.
Re:Database vs. XML Text Files (Score:5, Interesting)
Even on a very, very small dataset, do you want to run through n1*n2 or n1/n2 records? Very, very simple.
Imagine: you're in the library of congress. You need not just ONE book, but *A* book with X in the title. So, what's the point of having a database? I mean, we've got all these books and all the information is like there and stuff...
Re:Why MySQL and not PostGreSQL? (honest question! (Score:2, Interesting)
I hear that a lot without much to say beyond it. But it seems like everytime MySQL and pgSQL come up it's hard to wade through all the zealotry and bs to find any real answers. What exactly do you (and presumably others) base your lack of trust in MySQL's data storage on? I've seen a few personal accounts about how MySQL has f'ed up and lost people's data, but do you know what kinds of things lead up to that? Or, why it would be more likely under MySQL than any other database?
PEAR? (Score:5, Interesting)
shouldn't everyone be using PEAR::DB by now?
bad news when you decide you want to change your database because mysql can't handle the load without munging your data anymore....
(ok, so the jab at mysql was flamebait, but the rest is a serious question....)
Request for Comments (Score:3, Interesting)
I am on loan to this department, so I can't just finish the project in a weekend and then hand it to them. Rather it's going to be a fairly long drawn out educational process (~2 months @ 1/2 time). They need to be able to understand how it works, how to maintain it, how to enhance it. Essentially they need to be an integral/invested part of the development process.
Anyways, my initial idea was to have them use PHP alongside Pear's DB_DataObject [php.net] and eventually Html_QuickForm [php.net] libraries. For those not in the know, DB_DataObject is an object oriented data access layer generator framework thingy. Basically, instead of establishing connections, writing sql statements, and iterating over recordsets, they can write fairly simple code like the following.
require_once('some-config-file.php');
$student = new DB_Student();
$student->get(2);
print $student->name;
$student->name = "Bob Bobertson"; set students name.
$student->update();
Now when I see a newbie book teaching people to pound out their own sql and use old school mysql_connect style functions, I question my judgement. Is it a good idea or a bad idea to try to introduce these kinds of rapid development tools to novices? On one hand, these tools make my life easier on a daily basis. On the other hand, sometimes it's better to know the basics before going off to advanced topics like this. What do you guys think?
It should be noted that whatever happens we are not sticking with filemaker (not even my decision). We will either be using Access which doesn't appear to be supported by DB_DataObject or potentially Access/ADP/MSDE or Access/Linked/MySQL which both do work with DB_DataObject. I am desperately trying to set up something that lets them create/edit/drop tables from within Access and lets them easily design queries in access which are then usable with DB_DataObject.
Thus far, the closest I've come is using MSDE (light weight MS SQL Server) as the backend for Access. This is done using the Active Data Project (ADP) format not with linked tables. They can create/edit/drop tables and create views in Access. The views and tables are all reachable via DB_DataObject. However, there is no expression builder in the Access interface when working in this fashion.
This is problematic because these folks are more accustomed to using wizards to dump all of their messed up logic right into their database software. I can see them wanting to create numerous complicated views but not knowing how unless they learn a sizable chunk of TSQL. If they have to do that, the value of a library like DB_DataObject, which prevents them from having to write sql, is significantly reduced.
Personally, I think it all comes down to which they want to be easier: creating access forms/queries/etc or creating data driven web pages. Any thoughts?
Re:Watch your server go up in flames, QUICK! (Score:1, Interesting)
The why do so many PHP applications only support MySQL, with PostgreSQL supoort coming "Soon".
PHP actively discourages the use of database abstraction layers, because those that spout off about how easy it is show the mysql_* functions as their prime example.
The day that the mysql_* functions are marked deprecated, or removed and replace with a proper database abstraction layer that is promoted as heavily as the mysql_* functions are now, is the day that I'll admit that PHP is a language a new programmer should learn.
PHP encourages bad design because PHP is badly designed.
Nice book (Score:2, Interesting)
Re:Request for Comments (Score:2, Interesting)
Object oriented data access layers can sometimes be useful - but sooner or later you're going to do a complex query spanning multiple tables, and you'll wish you used SQL.
Usually the best approach is a combination, and if you design your data access layer correctly the SQL vs ORM decision doesn't have to be system wide.
If you're using Java or
Abstracting the database is ALWAYS a good thing. Books teaching the use of the mysql_* functions in PHP are simply WRONG, and should not be allowed to be sold. Those books are responsible for every slashdotted and vulnerable PHP site on the net, and contribute to the lack of good design principles.
I guess it might be worth mentioning ... (Score:2, Interesting)
1. Never programed in PHP! (Hell, never programed in ANYTHING before)
2. Never did ANYTHING database related before!
An all-general newbie to this kind of stuff. In one day, I learned how to create tables, insert data, display data on web pages, and all of the other basic stuff! At least a must-check-out for beginers! Ohh yeah, and "use the force, read the source"
PS - Must Explain why I still have a girlfriend!