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.
For the last time! (Score:2, Insightful)
DAre I say - a waist of money! (Score:5, Insightful)
And really, if you don't already have an understanding of basic DB design (tables, fields, records, data types, etc.) are you really going to be designing such a site? If you didn't, there are plenty of free resources on the web to help you do that.
Programming is primarily a self-starter job. You learn by doing, and by using free resources out there on the web. Why pay money for a book that regurgitates already free information for two pieces of free software.
Coding Standards? (Score:2, Insightful)
Re:DAre I say - a waist of money! (Score:5, Insightful)
Re:DAre I say - a waist of money! (Score:5, Insightful)
Programming well, on the other hand....
Re:SQLlite (Score:2, Insightful)
How to churn out vulnerable websites! (Score:5, Insightful)
2. Find the sections that tell you how to get it working.
3. Don't read any more about it.
Two words: "SQL Injection."
Mind your steps... (Score:4, Insightful)
whatever - is not important. Know the language you
program in BEFORE you start the project! Almost
all scripting languages have the database interfaces
you need.
2. Encapsulate recurring themes like database
selects, inserts and so on. Knowing your language
helps. Balance abstractness against usability.
3. Use a (at least moderate flexible) template
engine.
Then youre (almost) done.
In the last few years I used PHP and Perl. Both
have their advantages and horrors. PHP is getting
(even) better fast. Perl is quite nice if you know
it good, which could take a little time.
I only used MySQL and SQLite. MySQL with InnoDB is
very reliable under heavy loads and huge datasets,
but gets rather clumsy to back up and replicate.
SQLite is blazingly fast, but I cannot say anything
about reliability. I wont bet my crown-jewels on
it (yet).
Anyway. Good luck.
Better book idea (Score:4, Insightful)
Just a thought...
Please don't use direct connect (Score:4, Insightful)
A whole bunch of items are about to break beacuse people need to use mysqli. It would have been nicer if all these hacks used some db abstraction layer.
And anyone who has had to update some pages a newbie built, will say please learn to abstract the connection information into a single page, not one connection per page.
Ayeee.
Re:Database vs. XML Text Files (Score:3, Insightful)
Re:SQLlite (Score:3, Insightful)
Comment removed (Score:5, Insightful)
Do the same thing with 10 Minutes work (Score:3, Insightful)
Re:Mind your steps... (Score:1, Insightful)
program in BEFORE you start the project!
Dunno about that, the only way I've ever been able to learn anything is by using it for an actual project. Seems to work out ok.
Update is in order (Score:5, Insightful)
No completely wrong, but mostly:
* The current release of PgSQL runs natively on NT/2K/XP/2K3 Server as a service. The Cygwin emulation and related kludges are not an issue with either database now.
* PgSQL has been quite optimised in recent years, while at the same time MySQL has become rather less lightweight than it used to be. The only way to get any measurable performance benefit from MySQL over PgSQL now is to forego the use of InnoDB tables in MySQL (and the transactional ACID-compliancy/rollback capability that comes with them). Even then, it is only fast at SELECTs--speed of INSERTs, UPDATEs and DELETEs was never MySQLs real strom point in any case.
* As far as volume of hits and concurrent users go, PostgreSQL is far superior because it has a mature, stable MVCC (multi-version concurrency control) solution that almost completely eliminates table and record locking. If you have a site that does frequent and random insertion, deletion and modification transactions PgSQL wins.
* MySQL was perhaps simpler in the past, but that was because it's capabilities were much more limited. It isn't hard to use today, but it isn't exeptionally easy anymore. Furthermore, PgSQL has a lot more tools to ease administration tasks than it used to. I am puzzled by comments that PgSQL us hard to use--I actually find it is easier to use than MS SQL Server 2000 now. The documentation has come a very long way and you can point-and-click your way around PgSQL with PgAdmin, WebMin, and various PHP web-based tools.
* There are a lot of large-scale PgSQL implementations that rival or exceed Slashdot in scale. The entire
Anyways, I hope I haven't offended MySQL fans--it is a fine product and has enjoyed a great deal of success and advancement with its association with SAP for example. For a typical blogger/slashdot-style site MySQL fits the bill nicely as it has the largest installed base, doesn't handle mission-critical data, and the vast majority of activity is read-only.
If the data in the application is *important* and is write-heavy then you'll find that the case is different than above. For mission-critical web-based systems PostgreSQL tends to be be chosen over MySQL. For example, the SQL-Ledger accounting system uses PgSQL and NOT MySQL. However, MySQL has grown up some and has become a viable option here too--it's just that PgSQL has a more established image as being not the fastest but themost reliable with your data.
Just remember that if you decide to pass on InnoDB to max out performance of your MySQL database you better make damn sure you have a reliable UPS and don't trip on the power cord or bump the emergency power disconnect switch or you'll have a crisis on your hands...
Dynamic website == slow and CPU heavy (Score:5, Insightful)
Fully dynamic websites will crush your server.
Dynamic websites may be easy for beginners with this book, but introduce (a) a large amount of data or (b) a large amount of traffic (e.g. slashdot effect), and your server will fall over faster than a debutante in her first set of heels.
I was on the team that helped set up cnn.com [cnn.com], back in the "early days" of the Web. And more recently, during the U.S. presidential debates, I convinced FactCheck.org [factcheck.org] that their server would stop falling over, if they just exported their article database as static HTML files, rather than being 100% dynamic. (that indeed fixed the problem)
Dynamic content has its place, but too many newbies make the assumption that a fully dynamic website is a good idea. For content that does not change frequently, it is often more wise to use triggers to export the data as static HTML than to continually query and generate the same dynamic content over and over again. Database query caches help, but not a whole lot. Static HTML pages, and dynamic pages that provide the HTTP cache/expire/etag info are much more friendly to the web caching infrastructure in your browser and at your ISP.
Re:Update is in order (Score:2, Insightful)
1) Mysql has a much smaller memory-print. Try giving a database 4 or 8mb or ram to work with in both Postgres and Mysql and compare the performance. Postgres loses BIG time, while mysql runs without a glitch. Postgres is nice if you have 1 server dedicated to 1 application. Mysql is so popular because for low-end sollutions, it uses very little resources, which is exactly what mass-hosting companies need. Why do you think you see so little web-hosting with Postgres support?
2) 95% of the queries performed by websites are typicly SELECT's - which is Mysql's strongest point.
3) Most websites are not mission-critical. If you lose data - too bad, that are some blog's you lost, or maybe some reactions... Big deal. Btw - postgres's recovery after a powerfailure isn't perfect, I know a company that is switching to Oracle after a small postgres disaster half a year ago... They lost a rather critical table with +- 7 million records, and daily thousands are added.. Backup was from the day before, but they lost a whole day of pritty important transactions (crash happened at 21u in the evening, backup started at 21u30). No system is perfect, but now they have someone to blame...
4) Postgres's duplication can't tip mysql's. In postgres quick hacks are available, Mysql supports load balancing and mirroring over multiple servers by default, and it's far superior to anything Postgres has.
5) Postgres should be optimized for 1 application. There is no generic optimal configuration, differences in performance between applications can be extreme depending on the configuration.
Mysql has it's purposes, so does Postgres, but I don't think they are competitors actually. It all depends on what you really need. I have experience with both, and for web-purposes - Mysql please... I plan looking into SQLite, which I already use for embedded purposes, but don't know how that is going to react in a multithreaded environment like a webserver.