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.
In fairness, sometimes it depends on whether your hosting service bungs in PHP etc. free, or at extra charge. It's all part of the pros and cons when it comes to dealing with hosting services.
Personally, I prefer the ones that do throw in mySQL/PHP/etc. in with the deal - but there's a lot out there that dont, EasySpace being one of them. Yeah, I used them for a while, but now I don't - but they still charge through the nose for mySQL and PHP stuff, as well as most other things.
I say we take off and nuke it from orbit. It's the only way to be sure...
... 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
Putting an affiliate link makes the review so much more credible.
All 295 pages, every day? Wow... the only way this would be true for me is if I forgot how to count all the way up to 295 and had to make use of the page numbering.
Seriously, will somebody reset the hyperbole detector? Mine keeps going off.
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.
PHP indeed borrowed a lot of language features from Perl, but its syntax is strictly C-like; no required braces, no embedded regexps, no magical, one-character variables, etc., etc.
:)
I agree with you that PHP's functions are awkward, but I'm sure you can find a way to implement namespaces in PHP--PHP has classes, it has hashes, and it has an eval() function, so you can probably figure something out. What I really hate is how PHP handles variables and scoping--that's really criminal. Also, anonymous subroutines and closures would be nice to have...
I never really wanted to write as much PHP as I have, but I don't think it's difficult to be a competent PHP programmer--it's just like being a competent programmer. Just because a lot of people aren't doesn't necessarily mean that it's a problem with PHP. I admit that I'd rather be doing all this in Perl, though, because some of PHP's 'features' and version incompatibilities are a real pain sometimes. Maybe *that's* why it's hard to find competent PHP programmers...
There are tons of templating engines for PHP; I've basically hacked together my own solution as well. I haven't compared them, but doing everything in pure PHP seems pretty simple to me; it has an include() function, and that's really 99% of what you need.
So I agree with you that PHP has some serious problems, but I think I disagree with you about exactly what those problems are.
pb Reply or e-mail; don't vaguely moderate.
Um, no.
Real database connection pools (say, JDBC) running through a real application server (say, Resin) instead of a compiled-into-Apache-interpreter (PHP), accessing a robust database (Oracle) can and will run at an extremely high speed even when heavily loaded via Slashdot, etc.
All of these "create your own database-driven site!" beginner books are really nothing more than terrible instructions about how to build half-assed applications that don't scale worth a damn. It's because of these "learn PHP and MySQL in 30 days!" pseudo-manuals that we even have the slashdot effect. If web application programmers were to take the time to learn real enterprise-level application coding, you wouldn't see absolutely false statements like "opening a database connection for every visitor on every page is suicide".
php is a template engine, why build an other one on top of it like smarty does. The only thing smarty really does is force you to seperate business logic and layout. You can also do that without using smarty. I mean What is so much more difficult from using
compared to {$bla}
Yeah because every startup has the money to put tens of thousands of dollars into their hardware. Not to mention the many thousands of dollars to purchase the high end software. Oh yeah, how about the cost of programming these? What? We have to be able to maintain it all too? Hmm...how much will one or two knowledgeable and experienced admins cost? How many hits do we get per day, per hour, per minute? God help us if we ever want to change something. I'd like to see that ROI...actually...no...I wouldn't.
Everybody dies frustrated and sad and that is beautiful