Slashdot Mirror
Build Your Own Database-Driven Website
Unlike the arbitrary structure exemplified by so many programmers' references, Build Your Own Database Driven Website using PHP & MySQL is written more like an instruction manual, with chapters arranged in the order in which you should use them.
The first chapter explains the installation of PHP and MySQL; the next two cover usage basics. In Chapter 4 you're already pulling information from your database and publishing it on the Web. Chapters 5-10 refine what you've already accomplished, and delve into advanced topics in both PHP and MySQL.
If you're familiar with Yank's original tutorial, on which he based this book, your familiarity will end with the closing pages of Chapter 10. Chapter 11 addresses the storage of binary data in MySQL, a topic that was of great interest to me personally as I'd never done it before. In keeping with the rest of the book, Chapter 11 is a step-by-step guide, and explains the storage of binary data in a practical, down-to-earth manner that inspires you to give the book's teachings a try. Already I'm searching for an excuse to build a system, just to experiment with what I've learned. Chapter 12 covers cookies and sessions in PHP. The usage of cookies and sessions is essential to any online authentication or shopping cart system, and this topic makes a great final chapter that complements the book's other lessons.
This book makes good on its promise to teach you everything you need to know to build a database driven Website, but fortunately for us the author decided to throw in a few extras -- these take the form of four reference appendices. Appendix A covers MySQL syntax, which, while covered throughout the book, is easily referenced through this well-organized appendix. Appendix B explains MySQL functions, while Appendix C covers MySQL datatypes in considerable detail, so much so that I found this information easier to use than the official MySQL online reference. Finally, Appendix D covers the PHP functions that are used with MySQL.
If you progress in your programming skills you'll eventually need to buy a complete programmer's reference for PHP, although you probably won't need to buy an SQL reference unless you start using a more robust database solution than MySQL. However, if you want to build your first database-driven website, or even if you have built one before but want a practical reference, I can't recommend this book highly enough. Build Your Own Database Driven Website Using PHP & MySQL will guide you step by step through the development process -- who could ask for more?
You can purchase Build Your Own Database-Driven Website Using PHP & MySQL, 2nd Ed from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
... but aren't there already a bunch of books that do this? I mean, wouldn't a more useful book be one about *designing* a database driven site? Stuff like content management, implementing full text search, session tracking, user logins, site organization and navigation, that sorta thing?
I mean, do we really need *another* book that tells you how to program in PHP and how to use MySQL?
Anyway, from the review, I suppose this would be a good replacement for those books. I just think what we need is something more.
"Times have not become more violent. They have just become more televised."
-Marilyn Manson
I have a PHP book that's 567 pages long. I have two SQL books: one has 377 pages; the other has 719. Yet I consider 295-page 'Build Your Own Database Driven Website using PHP & MySQL' by Kevin Yank more valuable than any of these books.
Just because a book is long, doesn't mean it's useful.
like the great quote
The Ten Commandments contain 297 words. The Bill of Rights is stated in 463 words. The Lord's prayer has only 67. The story of creation in the Bible uses only 200 words. Lincoln's Gettysburg Address contains 271 words. On the other hand, a recent Federal directive to regulate the price of cabbage contains 26,911 words.
I personally find, the bigger the book, the more difficult it is to navigate and the less useful it really becomes. Quick, short, to the point explanations are almost always better than long details drawn out explanations that I don't have the time or the desire to read.
~ kjrose
I develop 'AMP' solutions and IMHO this book, in addition to the PHP cookbook, are the best two books you can buy on the subject. You can really tackle most any problem with these two books and if you cant, there is always IRC or as a last resort the documentation :)
I don't keep a lid on my coffee so when I walk around I look busy -me
It seems too many websites out there have mile-long URLs(including huge session ID strings) and other gizmos only to deliver the same static content over and over again.
What ever happened simply to static web pages that are nice and simple, and dish out the data without all that overhead?
when you actually start getting alot of traffic it is sometimes best to use static pages for as much content as possible .. of course these static pages are generated from information stored in a database ..
.. and your site is featured on slashdot ..
opening a database connection for every visitor on every page is suicide if you only have a single server
It all depends on what you're doing. Most business pages (brochurepages) are actually quite static and would not need much automation.
On a counterpoint, some homepages have dynamic content of some sort that you just can't do with static HTML. It's all a matter of what you're doing, not who you're doing it for.
Also, some people put up private pages as a way of teaching themselves the ins and outs of running webpages. Those pages can quickly include all sorts of bells and whisles including dynamic content, flash, etc. Additionally, those sights can look good on a Resume since it shows the person has enough interest in the technology to play with it outside of the workplace.
I read the internet for the articles.
It depends on what type of content you're putting up. I wanted consistent navigation from page to page and easier maintainability; server-parsed HTML is sufficient for that task. It also allows me to serve up either proper HTML and CSS for browsers that can handle it or broken, non-standard HTML for crappy non-standards-compliant browsers. While I use MySQL for logging server activity (when I dumped access_log into the database, the database was smaller than the text file that created it), the only "content" I've ever served up from it was statistics of how many tens of thousands of times infected IIS machines had tried to pass their bugs on to my server (done with server-parsed HTML and a shell script with the query). For mostly-static content on a small to medium website, is there any reason (other than "because I can") for shoving every website into a database?
Such as this one, which took forever to load because the images appear to have not been optimized? Looks like invalid HTML with a big table in it.
(Why do I get the sneaking suspicion I've just been trolled?)
20 January 2017: the End of an Error.