Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Build a Database Driven Site -- Quick

timothy posted more than 9 years ago | from the stupid-overlong-titles dept.

PHP 251

norburym (Mary Norbury-Glaser) writes "The third edition of Build Your Own Database Driven Website Using PHP & MySQL is written by Kevin Yank, Technical Business Director for sitepoint.com, a popular online resource for Web development. Updated for PHP 5 and MySQL 4 in this edition, Yank has put together an easy-to-follow, hands-on tutorial using the tools and techniques necessary to build a functional database-driven Web site. Many Web designers don't have deep knowledge and experience in data coding but want to get started serving up dynamic Web pages. This book gives designers and beginning coders a concise introduction to PHP and MySQL and quickly brings the reader to the page-creation stage." Read on for the rest of Norbury-Glaser's review.

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.

cancel ×

251 comments

Sorry! There are no comments related to the filter you selected.

Do you really need a book for this? (2, Funny)

Anonymous Coward | more than 9 years ago | (#11554592)

It's like boiling water these days.

Re:Do you really need a book for this? (4, Funny)

ArsenneLupin (766289) | more than 9 years ago | (#11554644)

It's like boiling water these days.

And using ASP/MsSqlServer is like pouring it down your crotch. And contrarily to popular opinion, Microsoft is not McDonalds ;-)

Re:Do you really need a book for this? (1)

Saeed al-Sahaf (665390) | more than 9 years ago | (#11554700)

Building anything with .asp is like pouring boiling water down your crotch.

Re:Do you really need a book for this? (1)

arkanes (521690) | more than 9 years ago | (#11554861)

Yes, but using PHP and MySQL is like pouring non-boiling, but germ infested sewer water down your crotch. You're almost certain to catch something.

Re:Do you really need a book for this? (5, Funny)

Anonymous Coward | more than 9 years ago | (#11554719)

> Microsoft is not McDonalds

But they're both run by scary-looking clowns.

McDonalds... (1)

Spy der Mann (805235) | more than 9 years ago | (#11554988)

And contrarily to popular opinion, Microsoft is not McDonalds ;-)

Well they DO fit the "Supersize me" theme :)

s? (0)

Anonymous Coward | more than 9 years ago | (#11554597)

Database driven S?

been loving php (-1, Offtopic)

Anonymous Coward | more than 9 years ago | (#11554601)

i love php..it helps me create great sites [bibleplayer.com] quickly!

Using PHP & MySQL to Build a Database Driven S (2, Funny)

rackhamh (217889) | more than 9 years ago | (#11554606)

Apparently a much needed book!

Re:Using PHP & MySQL to Build a Database Drive (1)

carpe_noctem (457178) | more than 9 years ago | (#11554640)

I was just using flat files for my S, and it was no good! Thanks to this book, my S is now running 150% faster and I can now start working on T-Z!

Re:Using PHP & MySQL to Build a Database Drive (3, Funny)

SupremeTaco (844794) | more than 9 years ago | (#11554731)

I guess they ran into the 46 character bug, wh

Database Driven S! (-1, Redundant)

ikewillis (586793) | more than 9 years ago | (#11554607)

Letters are always better when they're DATABASE DRIVEN!

Remember the good old days when the /. mods would at least check the headlines before posting stories?

Re:Database Driven S! (5, Funny)

emc (19333) | more than 9 years ago | (#11554822)

Remember the good old days when the /. mods would at least check the headlines before posting stories?

No

ROR! (1, Informative)

Ramses0 (63476) | more than 9 years ago | (#11554613)

ROR! -- "Using PHP & MySQL to Build a Database Driven S"

quickly changed to: "Build a Database Driven Site -- Quick"

MMmmmmmh @ Perl + Mysql. ;^)

--Robert

Re:ROR! (0)

Anonymous Coward | more than 9 years ago | (#11555412)

With all the editing the admins do to their own posts, you'd think they'd get around to letting us edit ours.

For the last time! (2, Insightful)

Anonymous Coward | more than 9 years ago | (#11554615)

A summary is NOT a review.

Using PHP & MySQL to Build a Database Driven S (0, Redundant)

Digital Pizza (855175) | more than 9 years ago | (#11554627)

Slashdot meets Sesame Street?

Re:Using PHP & MySQL to Build a Database Drive (3, Funny)

lucabrasi999 (585141) | more than 9 years ago | (#11554687)

"Today's Database was Driven by the Letter S and the Number 5"

Considering most of the sites I have seen (1, Funny)

Anonymous Coward | more than 9 years ago | (#11554641)

They were built extremely quickly. If they weren't built quickly, I can only surmise that these sites were all a product of those who ride the short bus.

SQLlite (4, Informative)

Philmeeh (189317) | more than 9 years ago | (#11554642)

If you really want to set up a quick database site then you may as well use SQLlite that comes bundled in PHP5. No need to worry about connecting to a separate mySQL server with all those niggling connections

Re:SQLlite (2, Insightful)

odyrithm (461343) | more than 9 years ago | (#11554845)

SQLite needs to connect to a db in the fs anyway, in much the same way as mysql, pgsql, mssql etc etc client needs a socket connection. Don't get me wrong SQLite owns your socks, but it's no easier to use than *the real* dbms's.

Re:SQLlite (2, Insightful)

arkanes (521690) | more than 9 years ago | (#11554993)

Eh? No. "connecting" in SQLite is managed by passing it a filename. It's orders of magnitudes simpler than installing, configuring, and connecting to a client/server RDBMs.

Re:SQLlite (1)

odyrithm (461343) | more than 9 years ago | (#11555419)

Eh? No. "connecting" in SQLite is managed by passing it a filename. It's orders of magnitudes simpler than installing, configuring, and connecting to a client/server RDBMs.

Maybe I've grown resilient to the ease of my own intellect in my young age.

Seriously though..

$ pacman -S mysql
$ /etc/rc.d/mysql start
$ mysqladmin -u root password 'newpassword'
$ mysql -u root -p
>create database somedb;
>grant all privileges on somedb to somedewd@somehost identified by 'somepassword';
>flush privileges;
>ctrl+d

really, common take the initiative, it will not bite!

Re:SQLlite (3, Informative)

XorNand (517466) | more than 9 years ago | (#11554963)

I tend to think along the same lines. Maybe I'm a bit of an elitist, or it's the fact that I despise contending with so many horrid DBs thrown together by people who had no clue what they were doing. I'm sorry, but these "implement technology x in minutes" books really rub me the wrong way. Why don't people take the time to learn how to properly use their choosen tools? I wouldn't expect to be able pick up a wrench today and then begin building an engine tomorrow. Designing a good relational database requires some know-how. If you want to do something fast, use a simple flat file.

DAre I say - a waist of money! (4, Insightful)

MBraynard (653724) | more than 9 years ago | (#11554669)

BAsed on this summary/review, this sounds like a re-write of the already free help files for PHP and MySQL. Truth is, you probably don't even need the MySQL help file as the PHP documentation covers interaction with the database pretty well and pretty much every webhost out there is running phpMyAdmin for the database management.

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.

Re:DAre I say - a waist of money! (5, Insightful)

anamin (796023) | more than 9 years ago | (#11554745)

Because it's nice to have all of that information put into a single reference. When I need to look up something at a later date I'd much prefer having a book that I can quickly find the info I need, rather than digging through google, or finding out the site I book marked is no longer in existance.

Re:DAre I say - a waist of money! (0)

Anonymous Coward | more than 9 years ago | (#11554919)


If you're looking something up at a later date, then what you're looking up has probably changed since the book was printed.

Re:DAre I say - a waist of money! (1)

Frymaster (171343) | more than 9 years ago | (#11554935)

When I need to look up something at a later date I'd much prefer having a book

really? i'd way rather have an electronic reference. witness:

  • i can't to a regex search on a book
  • my mozilla bookmarks never fall out of my browser when i shake it
  • i can copy the electronic version limitless without killing trees
  • the website gets updated everytime there's a change. the book gets update once every year or two and costs another $50

i could go on and on and on. but you'd probably want to punch me if i did...

Re:DAre I say - a waist of money! (4, Insightful)

DrEldarion (114072) | more than 9 years ago | (#11555304)

How many people who will be buying this book know how to do regex searches?

Re:DAre I say - a waist of money! (0)

Anonymous Coward | more than 9 years ago | (#11554811)

DAre I say - a waist of money!

A bit greedy, aren't you? I'd settle for just a pocket full.

Re:DAre I say - a waist of money! (0)

Anonymous Coward | more than 9 years ago | (#11554888)

Maybe the poster is referring to one of those funky money belts?

Re:DAre I say - a waist of money! (4, Insightful)

winkydink (650484) | more than 9 years ago | (#11554827)

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.

Programming well, on the other hand....

Re:DAre I say - a waist of money! (5, Funny)

StandardsSchmandards (828326) | more than 9 years ago | (#11554847)

Dare I say - a waist of money!

My waist is mostly made up of fat. I would be happy if it was made of money. I could have used the money to buy a good PHP book.

Re:DAre I say - a waist of money! (1)

Tablizer (95088) | more than 9 years ago | (#11554961)

BAsed on this summary/review, this sounds like a re-write of the already free help files for PHP and MySQL.

People, please stop saying this. Altough the web makes a great reference, for learning new stuff I find books can be nicer for the following reasons:

1. They are easier on the eyes. At least for me, paper is just clearer and less tiring over the long-haul. Screens still have catching-up to do in this deparment.

2. Easy to grab a pencil and mark the damned thing up, drawing lines, arrows, circling stuff, etc. The computer techology to do something similar is not up to snuff yet.

3. Real estate. One can have the book open and their work on the screen at the same time. If you use your screen for both the training material and your work, then you have to keep swapping back and forth. A book is like a second monitor.

4. No plug. Books are portable and work well in direct sunlight. I can take one outside to peruse while keeping an eye (or ear) on the kids.

Re:DAre I say - a waist of money! (1)

LurkerXXX (667952) | more than 9 years ago | (#11555025)

5. Your time is worth something. Yes, you can find all sorts of useful tips and manuals for everything online. But it can take time to track down the good sources. Haveing someone else already do that and index and collate it for you is very handy.

Re:DAre I say - a waist of money! (1)

Tablizer (95088) | more than 9 years ago | (#11554999)

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?

Perhaps some companies run out of graphics work and so wish to move a web designer into programming rather than fire them. It happens.

A PHP developer's review (1)

Spy der Mann (805235) | more than 9 years ago | (#11555157)

Let's get things straight. This book is for newbies or for those who want a quicksearch reference. After all, what non-newbies title doesn't include "build your own"? (For more advanced users, I recommend the PHP Anthology [sitepoint.com] which deals with more complicated stuff, like FTP, thumbnail generation, search engine friendly urls, etc.)

I began programming in PHP+MySQL around 2 years ago, and this book practically taught me everything.

The book had a nifty section on administrating your MySQL database (specially useful when you forget your password :-P ). But the part that has helped me the most is the reference (Appendices).

Appendix A: MySQL syntax (with all the optional parameters)
Appendix B: MySQL functions. For example, what command do we use to search a substring in mysql? Quick search Appendix B... there! LOCATE.
Appendix C: MySQL column types. I don't use MySQL commands often, except when I add a module to my PHP framework (programmed by myself). so when I want to know how to specify a certain type, it's all there.
And finally, Appendix D: PHP functions for working with MySQL.

When you have read this book and have it in your office drawer, flipping thru some paper pages is definitely much faster (at least for me) than typing the search terms on the keyboard. So I recommend it to anyone wanting to learn PHP and MySQL. And to anyone who wants a reference handy :)

(off-topic Grammar Nazi hint: It's "waste", not "waist". Waist is what you get when you waste too much money on junk food)

Leans more toward the DB side (4, Informative)

bbzzdd (769894) | more than 9 years ago | (#11554681)

As the title suggests. Nothing about PHP templating technology (like Smarty) which can lead to some pretty gnarly PHP code. I'd recommend following this book up with Advanced PHP Programming [amazon.com] by George Schlossnagle as it focuses more on PHP.

Build a Database Driven Site -- Quick (3, Funny)

Anonymous Coward | more than 9 years ago | (#11554683)

Shouldn't that be "Quickly", or are we allowed to modify verbs with adjectives on Slashdot?

Re:Build a Database Driven Site -- Quick (0)

Anonymous Coward | more than 9 years ago | (#11554776)

I would presume that the "Quick" was used as an interjection following an imperative rather than as an adverb.

The ! exclamation mark that should have followed was probably missed due to following the imperative too quickly...

Re:Build a Database Driven Site -- Quick (1)

anagama (611277) | more than 9 years ago | (#11554793)


  • Shouldn't that be "Quickly", or are we allowed to modify verbs with adjectives on Slashdot?

No. It is "quick". Remember all the apple stories recently? Slashdot has learrned to "think different".

Re:Build a Database Driven Site -- Quick (0)

Anonymous Coward | more than 9 years ago | (#11554797)

You be lucky find grammer and speling that is readable also it not details that matter just contentss

Re:Build a Database Driven Site -- Quick (1)

arkanes (521690) | more than 9 years ago | (#11554841)

Notice the emdash. As punctuation, and in this case, it's used to conjoin 2 seperate statements, much like a colon or semi-colon -- allowing the author to combine two seperate but related thoughts into once sentence.

Re:Build a Database Driven Site -- Quick (0)

Anonymous Coward | more than 9 years ago | (#11554934)

"Quick" is also an adverb.

Re:Build a Database Driven Site -- Quick (1)

rot26 (240034) | more than 9 years ago | (#11555408)

"Quick" is also an adverb.

No, it's not. It's one of many adjectives that you can convert into an adverb by adding "ly" to the end.

Coding Standards? (2, Insightful)

codesurfer (786910) | more than 9 years ago | (#11554698)

I wish these books would include a section or two on properly coding web apps and sites. Often people who begin coding with weakly typed languages such as PHP (not a knock against it) do not become familiar with proper design and memory management.

Re:Coding Standards? (0)

Anonymous Coward | more than 9 years ago | (#11554862)

I think it's safe to say that you don't have to use a weakly-typed language to NOT become familiar with proper design and memory management. I've seen plenty of C#/Java/'insert your favorite typed language here' code that was designed poorly, and ran just as poorly.

This book's subtitle (0)

Anonymous Coward | more than 9 years ago | (#11554706)

(Even though what you are building probably doesn't even need javascript, let alone a database)

quicker to roll your own vs. pre-made (2, Interesting)

TeeJS (618313) | more than 9 years ago | (#11554730)

I'm always amazed when books claim 'quick' web development with MySQL and PHP. I think the planning of data structures alone makes this a not quick process. With like a gazillion pre-made CMS's available for demo at OpenSourceCMS (http://www.opensourcecms.com/) wouldn't that be the 'quick' way to go?

Re:quicker to roll your own vs. pre-made (1)

eltoyoboyo (750015) | more than 9 years ago | (#11555045)

I suspect that the target audience of this book are the authors of every code offering on OpenSourceCMS.com [opensourcecms.com]

I agree with you. Same goes for shopping cart sites and blog sites. Check out SourceForge [sourceforge.net] for a gazillion more php/mySQL applications like bug trackers and portals.

Then check out Nuke Cops [nukecops.com] to read up on the perils of mySQL/PHP in highly visible sites. They have logs of plenty of known exploits due to coding problems.

I learned my PHP using Kevin Yanks tutorials (5, Informative)

SpaceKow (24359) | more than 9 years ago | (#11554744)

I learned PHP using Kevin Yanks tutorials and articles 4 years ago. His books and tutorials are very easy to understand and use. His tutorials and articles can be read on http://sitepoint.com/

Advertising (0)

Anonymous Coward | more than 9 years ago | (#11554748)

I hope SitePoint is paying for all this advertising. That's like 3 book reviews in the past little while?

Should make for Firebird (1)

SirChris (676927) | more than 9 years ago | (#11554762)

They should make this with firebird sql and php. would be much more powerful.

Did you Hear? They cancelled Star Trek! (-1, Offtopic)

krudler (836743) | more than 9 years ago | (#11554815)

And we're talking about this?!

http://www.startrek.com/startrek/view/news/article /9469.html

:(. [TEARS REMOVED]

I flagged for lameness! For my tears? My tears are concidered lame? Do the people at slashdot have no heart? OMG Star Trek was just cancelled!

In korea only old men watch star trek (1)

Gundampilotspaz (651286) | more than 9 years ago | (#11554898)

My God what reason do I have to live anymore! For the love of God it was getting cool! I want to see a Romulan War God damnit amd if I don't then Berman will pay!

Database vs. XML Text Files (2, Interesting)

markmcb (855750) | more than 9 years ago | (#11554831)

I recently threw together a rather Slashdot'ish site (http://www.omninerd.com/ [omninerd.com] ) and I used XML text files with PHP (and XSLT) over the mySQL alternative. Now, I'm no DB expert, but is there really any need for most sites to be DB driven? For example, on my site, there are articles, and the news posts that introduce these articles that readers can comment on. Perhaps I'm missing the big picture, but why would I need a DB solution when XML files get the job done, are easily portable, and can be accessed without the use of a DB program. I understand for extremely large data sets a DB is probably what you want, but what about small timers like me? Is a DB solution a waste of my time, or am I missing something big?

Re:Database vs. XML Text Files (2, Insightful)

prostoalex (308614) | more than 9 years ago | (#11554962)

Two things that come to mind is search and scalability. Can you conduct quick searches through the files, and will the system scale if you become as popular as Slashdot, with thousands of daily updates (in form of user comments).

Re:Database vs. XML Text Files (2, Informative)

dreadlord76 (562584) | more than 9 years ago | (#11554980)

You are missing something.... Big...

In a small database application, used by, let say, 500 users a month. There can easily be hundreds of thousands of records. Come end of month, you need to find 50 records out of 100,000 that meets certain criteria. How are you going to get that out of the XML text files? Read all 100,000 and then parse it?

The fact that there may be 100000 text files out on disk should be causing all sort of alarms to go off.

Re:Database vs. XML Text Files (1)

C10H14N2 (640033) | more than 9 years ago | (#11555366)

But, wait, there's MORE!

One poorly written query and you have the potential for a resultset of n^n. Even a modest 100,000 records could produce a query traversing a quadrillion records or more. If the person designing the application thinks that 100,000 XML files would be efficient, I have 100% faith that they would write something like:

SELECT t1.x, t2.y, t3.z from onetable t1, onetable t2, onetable t3;

...now imagine their algorithm for doing that with said 100k XML files...

Re:Database vs. XML Text Files (5, Interesting)

C10H14N2 (640033) | more than 9 years ago | (#11555027)

Indexing.

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:Database vs. XML Text Files (1)

neworbits (237906) | more than 9 years ago | (#11555061)

Well, I was a small-timer four years ago, but not planning on staying that way, I hired out the development, since books and onlne documentation reflect the utter inability of writers to sequence a series of steps in the natural order of an uninitiated person's need to know (except I suppose when it comes to vaulting their boogers).

Once it was developed, I was able to grow from 100 products to over 3000, and now I am building a mirror site as a backup to the production site using what I see in the structure of the current one via phpmyadmin. That and consulting the programmer I originally hired have been far more instructive than any book or online documentation. And considering the time factor saved, it's actually costing less than trying to disentangle the usual convoluted book or documentation.

Re:Database vs. XML Text Files (2, Informative)

halosfan (691623) | more than 9 years ago | (#11555121)

If you truly want to understand this, read through the first couple chapters of the Date book [bookpool.com]

For a brief answer, your XML files (and most OO databases as an extension) might work well for your application, but try using them for a totally different application that works with the same data. That's where relational model (at least in theory) shines: it is application-agnostic.

Additionally, as your application grows and so is the number of concurrent users, you might face issues that are just not trivial/too tedious to program by hand:

  • Transaction support. For example, you transfer $5000 from your savings account to your checking account, and the power goes down when your savings account is debited but before your checking acount is credited. If you don't explicitly code around this problem, $5000 disappears.
  • Transaction isolation. Same example as above, but instead of power outage, a program that generates your paper statement is run -- $5000 is not on the statement, even though it is in your account.
  • Durability. Same example, power goes down. Try it enough times, and depending on which filesystem your XML file is on, you may well see it corrupted when you boot the machine after power is restored.
  • Consistency/integrity. Same example, your checking account balance is stored in a two-byte unsigned integer and is currently at $63,000...

Try Date's book for more detailed (and likely more clear) explanation.

The good ol' days (2, Interesting)

Tablizer (95088) | more than 9 years ago | (#11554834)

In the early 90's many companies were working hard on data-centric products that took the grunt-work out of typical "CRUD" screens ("Create, Read, Update, Delete"). The leaders were probably PowerBuilder and Clarion, with VB and MS-Access barrowing some of the concepts to a more limited extent.

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.

Re:The good ol' days (4, Informative)

wackysootroom (243310) | more than 9 years ago | (#11555099)

The main problem with Clarion is that while it's easy to whip up a quick toy app, it plain dead sucks for anything more than an address book or recipe book with anything more than a couple of 1:many relations.

Clarion was (at least from my experience with 5.0-5.5) riddled with bugs in it's QBE template and softvelocity's solution was to buy a template that fixes the problem from a third party until the next version comes out. No thanks.

Another thing that pissed me off about clarion is that you would get buried in dialog boxes very quickly while clicking away at options with the mouse. Definetly not productive. Another fond memory I have is trying to figure out what event to use to do a certain action from the event model. The clarion community's response? Just keep trying different ones until you find one that works. I suspect that there's not one person who fully understands the event model.

If it's CRUD you want along with maintainability and separation of business logic, view and data model. Try Ruby On Rails. You can literally develop a "toy" app 5 times faster in ROR than you could in clarion that does all of your CRUD stuff.

Re:The good ol' days (1)

Tablizer (95088) | more than 9 years ago | (#11555241)

A lot of tools don't bother to make their event handlers very visible or tweakable. A lot of GUI tools suffer from this.

One solution I would like to see tried is clear priority rules with each event having an alterable priority. For example, field-specific validation events should normally fire before form-level ones. But one should be allowed to tweak a form-level (default) priority value if needed to make it fire first.

And, it would be nice if traces of the events were loggable so that one could review them for debugging.

I have proposed putting all the events and GUI widgets (or at least references to them) in a database so that one can query and study events in a consistent manner. But, some complain that this would make it too slow. I dispute that because FoxPro uses its semi-relational engine for some of such things, and it is generally pretty peppy. (However, a full-blown relational engine may have a different story.)

I wish somebody would give me a grant to build such a contraption in full because I have been itching to do it.

No mention of Security (5, Informative)

kevin_conaway (585204) | more than 9 years ago | (#11554856)

The review didn't touch on security. I think that when you're trying to teach beginners and/or non-programmers how to build web applications, a good foundation on computer security principles is a necessity.

Basic things like input validation and protecting against XSS are a MUST when dealing with PHP (or any language for that matter). Since beginners are the ones most likely to make these mistakes, it is important that they be educated now.

Re:No mention of Security (0)

Anonymous Coward | more than 9 years ago | (#11555291)

And the funny thing is, NOBODY seems to want to publish information about validating input across a whole application. How many times do we need to be told how to validate an email address? There must be a way to automate the process of determining how variables should be validated. Every application should be able to use the same basic validation routines so why does everyone have to use a different technique?

How to churn out vulnerable websites! (4, Insightful)

lukewarmfusion (726141) | more than 9 years ago | (#11554865)

1. Buy a book about how to make database-driven websites.
2. Find the sections that tell you how to get it working.
3. Don't read any more about it.

Two words: "SQL Injection."

Re:How to churn out vulnerable websites! (1)

Tablizer (95088) | more than 9 years ago | (#11555350)

Two words: "SQL Injection."

If one is careful they can greatly reduce this risk. One trick is to put all read-only queries under a separate login from writable ones. This way no matter how tweaked the string is, the database won't do anything to change information.

For writable queries, just have wrappers that check the validity and perhaps perform any quoting/escaping/validating that is needed. Example:

$sql = "update x set foo=".sqlText($foo)." where xID=".sqlNumber($xID);

Why MySQL and not PostGreSQL? (honest question!) (4, Interesting)

leoboiko (462141) | more than 9 years ago | (#11554894)

No flames, please. I never really studied MySQL (other than installing, configuring, fiddling with Wordpress DBs, etc.), since my scholarship's teacher is a fan of PostGreSQL and I learned it first. Now I'm curious about why MySQL is so popular. Everytime someone is talking about a database-driven website it's Perl+MySQL, PHP+MySQL, Ruby+MySQL. What distinctive characteristics does it have over PostGres? Is it faster? Why do you like it so much?

Someone said to me that it's simpler, but from the little that I tried they seemed to have pretty much the same complexity.

Re:Why MySQL and not PostGreSQL? (honest question! (3, Informative)

danieljpost (455925) | more than 9 years ago | (#11555006)

I'll bite. Mysql installs & runs on Windows without any third party software. (Yes, the Web really runs on Linux. I know, I know.) PostGreSQL seems to run on Windows only in emulation (via Cygwin). Also, there used to be very slight performance differences (in terms of maximum numbers of hits to the DBMS per second, on simple benchmark datasets), and people seem to enjoy the idea that someone the same box could take 20,000+ hits in an hour using Mysql rather than 19,000 on the same hardware using PostGreSQL. This was a couple years ago so could be completely wrong now. I think there might also be a perception that MySQL is easier to use than PostGreSQL (based, I think, on pronunciation of the name). Plus, Slashdot uses MySQL. Those are the reasons I can think of. YMMV.

Re:Why MySQL and not PostGreSQL? (honest question! (2, Informative)

egoots (557276) | more than 9 years ago | (#11555240)

Mysql installs & runs on Windows without any third party software. (Yes, the Web really runs on Linux. I know, I know.) PostGreSQL seems to run on Windows only in emulation (via Cygwin).

This is no longer true! PostgreSQL 8.0 was recently released [postgresql.org] and one of the main feature enhancements is a Win32 Native Server

It's a simple, solid DB. (1)

TheLittleJetson (669035) | more than 9 years ago | (#11555068)

MySQL installation is pretty brainless. Unpack the archive, tweak the config file, start it up, and create your users.

It's pretty fast, very stable, and has an excellent front-end available. [phpmyadmin.net] Basically, it does the job, and it does it well. There are certain advanced DB tasks that you might need a more robust SQL implementation for, but for general purpose DB work, there's really not much reason to use anything else.

PostgreSQL is awesome, but last time I set it up, it was definately more work than MySQL.

Re:It's a simple, solid DB. (0)

Anonymous Coward | more than 9 years ago | (#11555129)

MySQL installation is pretty brainless. Unpack the archive, tweak the config file, start it up, and create your users.

And exactly how does this differ from PostgreSQL?

Re:Why MySQL and not PostGreSQL? (honest question! (1)

sfritzd (181571) | more than 9 years ago | (#11555086)

I don't think it has to do so much with complexity or simplicity or anything like that, but actually more to do with the appearance of simplicity. MySQL has a ton of really good documentation in many places on the web, whereas Postgres has a crappy online manual that even folks with years of experience with other dbs find confusing (like, um, me).

Also, for select intensive applications MySQL is faster. And you don't need to worry about optimizations like you need to with postgresql. Vacuum? I don't even do that to my house.

Re:Why MySQL and not PostGreSQL? (honest question! (1)

alienmole (15522) | more than 9 years ago | (#11555091)

MySQL started out a lot simpler - actually quite severely limited compared to PostgreSQL - but its simplicity is part of what attracted a large community. The community created network effects which have a lot to do with MySQL's continued dominance - more people are familiar with it, more packages already use it, so it makes sense to pick it for new projects, especially now that many of its original limitations have been overcome.

Re:Why MySQL and not PostGreSQL? (honest question! (1)

Silas (35023) | more than 9 years ago | (#11555117)

Here's some research my company put together on why PostgreSQL is better [summersault.com] (for us, and for web app development, anyway) than MySQL and others. We couldn't find any such comparison in existence when we looked, so I hope it's useful to someone, and we certainly welcome comments.

Silas

Re:Why MySQL and not PostGreSQL? (honest question! (3, Informative)

JohnsonWax (195390) | more than 9 years ago | (#11555136)

mySQL is popular now because every hosting firm offers it as an option, but Postgres is far less common.

Further, most web service add-ons (CMS, forums, etc.) are mySQL based out-of-the-box so it has become the platform on which to build.

You'll notice there are no technical reasons there - as RDBMS go, mySQL is pretty horrible. It's the Windows of free databases, as it were.

Re:Why MySQL and not PostGreSQL? (honest question! (1)

sloanster (213766) | more than 9 years ago | (#11555184)

Now I'm curious about why MySQL is so popular

Two words: blazing fast.

I first compared mysql and postgres in the 1999 era, and found mysql to be like a stripped down hot rod, fast and without frills, though fun to use. Postgres was like a classic cadillac in comparison. Large, ponderous, full of features and amenities. But when it came to performance, mysql just blew postgres out of the water. I ran a number of benchmark tests, and in some cases postgres and mysql were fairly close, while in other tests, postgres took 10 times as long as mysql. In a number of the tests, postgres couldn't finish in a reasonable time, so the results were interpolated.

Postgres fans pointed out that what with all the features and sophistication of postgres, it wasn't fair to benchmark it against mysql.

Fast forward to January 2005. Postgres has gotten faster, while mysql has gained features such as subselects, row-level locking, transactions and more. I ran the sql-bench test suite against mysql 4.0.22, and postgres 7.4, both completely stock, with default configurations as shipped with suse 9.2.

As it turns out, mysql was still an order of magnitude faster on some tests, while mysql and postgres were close on only a few of the tests.

I find mysql extremely easy to work with, as well as being lightweight. There's a reason that Mysql is the M in LAMP, after all.

Re:Why MySQL and not PostGreSQL? (honest question! (1)

egoots (557276) | more than 9 years ago | (#11555297)

"As it turns out, mysql was still an order of magnitude faster on some tests, while mysql and postgres were close on only a few of the tests."

Which table type was used in the the default MySql setup?

Zombie action and movie sites (1)

zee_zack (855831) | more than 9 years ago | (#11554906)

Well I run a MYSQL and PHP movie site. It takes time to debug and build a list of films in the database, checking to make sure it is not of the same name. We interviewed some retro actors too. http://insomniacmania.com/ [insomniacmania.com] I have also written a crazy movie script that may interest some. http://insomniacmania.com/forum/viewtopic.php?t=20 05 [insomniacmania.com]

Mind your steps... (3, Insightful)

LuckyStarr (12445) | more than 9 years ago | (#11554907)

1. Which language you use - be it Perl, php,
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.

Does it cover appropriateness to task? (3, Interesting)

Matey-O (518004) | more than 9 years ago | (#11554912)

I've seen _dozens_ of live database queries to fill a 'State' dropdown on a website... ...when was the last time we ratified a new state?

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.

Re:Does it cover appropriateness to task? (1)

Anonymous Custard (587661) | more than 9 years ago | (#11555031)

I've seen _dozens_ of live database queries to fill a 'State' dropdown on a website... ...when was the last time we ratified a new state?

Even a static file that's updated when needed would be sufficient and better than live hits to the database.

Re:Does it cover appropriateness to task? (1)

Tablizer (95088) | more than 9 years ago | (#11555054)

I've seen _dozens_ of live database queries to fill a 'State' dropdown on a website... ...when was the last time we ratified a new state?

With Bush in office, we should be ready for all kinds of changes, such as a Civil War between red and blue states; Iraq, Iran, France, and/or N.Korea being added, etc. :-)

Re:Does it cover appropriateness to task? (0)

Anonymous Coward | more than 9 years ago | (#11555152)

've seen _dozens_ of live database queries to fill a 'State' dropdown on a website

Lazy developers do this because they don't want to have to copy and paste the options from page to page. :)

be quick or be dead (1)

aled (228417) | more than 9 years ago | (#11554940)

Many Web designers don't have deep knowledge and experience in data coding but want to get started serving up dynamic Web pages.

When I read this kind of article I can't help but feel shudders. I wouldn't touch one of this sites even with a disconnected PC.

Better book idea (4, Insightful)

JeffHunt (129508) | more than 9 years ago | (#11554942)

"Build a Database Driven Site - With a Skilled Contractor Who Actually Knows What He's Doing"

Just a thought... :)

Watch your server go up in flames, QUICK! (4, Interesting)

C10H14N2 (640033) | more than 9 years ago | (#11554945)

Connection pools are your friend... and rather hard to use without an app server, which kinda spoils all the fun of writing PHP, the point of which is generally being able to avoid having to use one in the first place.

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...

Re:Watch your server go up in flames, QUICK! (1)

frn123 (242374) | more than 9 years ago | (#11555190)

Isn't that just writing mysql_pconnect instead of mysql_connect in php. And i'm quite sure that there's a Apache::Something module for mod_perl that does the same.

Please don't use direct connect (3, Insightful)

just someone (13587) | more than 9 years ago | (#11554955)

And teach people how to abstract connection information in a separate page.

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:Please don't use direct connect (1)

GeneralTao (21677) | more than 9 years ago | (#11555337)

I'm interested. Can you expand on that?
I am just getting started with this kind of stuff.
Do you mean that I should learn how not to make each load of a self-referencing php file establish a new connection?

How do I do this abstraction you're talking about? I presume it involves session IDs or some such? Any info would be appreciated.

What PHP really needs (3, Interesting)

ShatteredDream (636520) | more than 9 years ago | (#11554965)

Is something analogous to Web Forms. It'd be a great way to encourage people to work towards XHTML compliance if they could write some really slick UI with PHP and "PHP Web Forms" that could be manipulated directly from PHP rather than processed as a regular HTML form.

Then again, I suppose working namespace support is probably a more pressing concern at this point.

Build a Database Driven Site -- Quick? (1)

mr_zorg (259994) | more than 9 years ago | (#11554966)

Maybe we should focus on building a site well, not quick? How many PHP/MySQL driven sites have you been to only to be greeted by error pages? Note that I'm not blaming the technology, only those who put them together "quick" and "easy"...

Re:Build a Database Driven Site -- Quick? (0)

Anonymous Coward | more than 9 years ago | (#11555222)

"How many PHP/MySQL driven sites have you been to only to be greeted by error pages?"

Why, every one that Slashdot links to, of course.

YAPHPAMYSQLB (0)

Anonymous Coward | more than 9 years ago | (#11555080)

Yet Another PHP And MYSQL Book. Good-Fucking-God. Mysql sucks ass.

RoR is gaining traction (4, Informative)

5n3ak3rp1mp (305814) | more than 9 years ago | (#11555176)

Coming from some work in PHP, I've been burying my head in Ruby lately, to much joy, and have also discovered Ruby on Rails [rubyonrails.com] , which was also featured in a recent Slashdot article. What I've seen is amazing so far (not to mention that Ruby code is so much more readable than PHP that it's not even funny). Just an FYI...

DB::File (0)

Anonymous Coward | more than 9 years ago | (#11555340)

Perl has built in database support. Why use SQL at all?

No "Hello, World!" ?????? (0)

Anonymous Coward | more than 9 years ago | (#11555417)

I'll save my money, thank you!
Load More Comments
Slashdot Login

Need an Account?

Forgot your password?

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>