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.
Do you really need a book for this? (Score:2, Funny)
Re:Do you really need a book for this? (Score:4, Funny)
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? (Score:2)
Re:Do you really need a book for this? (Score:2)
Re:Do you really need a book for this? (Score:5, Funny)
But they're both run by scary-looking clowns.
Re:Do you really need a book for this? (Score:2)
Using PHP & MySQL to Build a Database Driven S (Score:3, Funny)
Re:Using PHP & MySQL to Build a Database Drive (Score:2)
Re:Using PHP & MySQL to Build a Database Drive (Score:3, Funny)
ROR! (Score:2, Informative)
quickly changed to: "Build a Database Driven Site -- Quick"
MMmmmmmh @ Perl + Mysql.
--Robert
For the last time! (Score:2, Insightful)
SQLlite (Score:4, Informative)
Re:SQLlite (Score:2, Insightful)
Re:SQLlite (Score:3, Insightful)
Re:SQLlite (Score:2)
Re:SQLlite (Score:3, Informative)
-kaplanfx
Re:SQLlite (Score:4, Informative)
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! (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.
Re:DAre I say - a waist of money! (Score:5, Insightful)
Re:DAre I say - a waist of money! (Score:2)
really? i'd way rather have an electronic reference. witness:
i could go on and on and on. but you'd probably want to punch me if i did...
Comment removed (Score:5, Insightful)
Re:DAre I say - a waist of money! (Score:5, Insightful)
Programming well, on the other hand....
Re:DAre I say - a waist of money! (Score:5, Funny)
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.
A PHP developer's review (Score:2)
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 us
Re:A PHP developer's review (Score:2)
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 func
Re:A PHP developer's review (Score:3, Informative)
Take a look here [php.net]
Notice that there are notes. User notes. Those are often more valuable to me than the documentation. No book has those. That is why the online/print it out solution is infinitly better.
Re:DAre I say - a waist of money! (Score:2)
Re:DAre I say - a waist of money! (Score:2)
If you're on a dialup I could see how a book could be resonable. Otherwise - take a database-course/class (cause theres no way you'll learn it the proper way without it anyway) and start hacking.
Re:DAre I say - a waist of money! (Score:2)
I am building such a site right now and I am a total hacker. We don' need no stinkin' BOOKS.
Re:DAre I say - a waist of money! (Score:2)
Leans more toward the DB side (Score:4, Informative)
Build a Database Driven Site -- Quick (Score:3, Funny)
Re:Build a Database Driven Site -- Quick (Score:2)
No. It is "quick". Remember all the apple stories recently? Slashdot has learrned to "think different".
Re:Build a Database Driven Site -- Quick (Score:2)
Coding Standards? (Score:2, Insightful)
quicker to roll your own vs. pre-made (Score:2, Interesting)
Re:quicker to roll your own vs. pre-made (Score:2)
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 (Score:5, Informative)
Database vs. XML Text Files (Score:2, Interesting)
Re:Database vs. XML Text Files (Score:3, Insightful)
Re:Database vs. XML Text Files (Score:3, Informative)
In my experience, (e)grep usually finds me a match much faster than SQL searches in whatever DB system we're using. I keep wishing this weren't true, b
Re:Database vs. XML Text Files (Score:2, Informative)
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 (Score:2)
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;
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:Database vs. XML Text Files (Score:2, Informative)
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 triv
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.
Re:The good ol' days (Score:5, Informative)
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 (Score:4, Informative)
As a matter of fact I can confirm that this figure holds true for any size of application. I developed the e-commerce software powering www.snowdevil.ca 5 times faster then would have been possible without ruby on rails.
This includes XMLRequest powered backend, inventory, order processing, credit card clearing, encryption and so on and so on and so on.
Alone... in 3 months... while publishing an array of opensource tools and having fun doing so
Perhaps an ebedded database? (Score:2)
I also agree that it would be nice to expose the event handlers more in GUI development tools, instead of requiring you to go through layers... it really seems like a lot more could be done to visualize GUI layout along with behind the scene components together than has been done up until now.
No mention of Security (Score:5, Informative)
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.
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."
Re:How to churn out vulnerable websites! (Score:2)
Cheers,
Adolfo
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.
Re:Why MySQL and not PostGreSQL? (honest question! (Score:3, Informative)
Re:Why MySQL and not PostGreSQL? (honest question! (Score:2, Informative)
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
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...
It's a simple, solid DB. (Score:2)
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:Why MySQL and not PostGreSQL? (honest question! (Score:2)
Silas
Re:Why MySQL and not PostGreSQL? (honest question! (Score:4, Informative)
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! (Score:2)
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,
Re:Why MySQL and not PostGreSQL? (honest question! (Score:2)
Cheers,
Adolfo
Re:Why MySQL and not PostGreSQL? (honest question! (Score:2)
There's also such a thing as programming idioms. Translating a set of non-ACID MySQL queries verbatim to PostgreSQL isn't likely to give good performance, in much the same way that writing C in Python is going to be dog slow. It doesn't seem to like getting bogged down in the hundreds of tiny individual queries that people used to fire off to MySQL back when they us
Re:Why MySQL and not PostGreSQL? (honest question! (Score:2)
The default MyISAM tables were used.
I'll test again using the more capable innodb tables when I get a chance...
Re:Why MySQL and not PostGreSQL? (honest question! (Score:4, Informative)
personally i would never use mysql for data that i didn't want to risk losing, although i have no doubt that it has improved substantially since the last time i had the pleasure of using it. but that's just me.
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
Re:Why MySQL and not PostGreSQL? (honest question! (Score:2)
i worked at another job where we were using mysql to ba
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.
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.
Re:Does it cover appropriateness to task? (Score:2)
Even a static file that's updated when needed would be sufficient and better than live hits to the database.
PHP is the Visual Basic of the web. (Score:2)
That is one of the main reasons that made me settle for ASP.NET on the app servers and linux on the database and NSF servers. I get built in caching capabilities so I can decide to keep the State query on memory or on disk for, lets say, a day.
Yes, I know that the same thing can be achieved with PHP and third party products, but my point is that PHP is a frie
Re:Does it cover appropriateness to task? (Score:2)
when was the last time we ratified a new state?
Perhaps a little more often than we change centuries? But that's never caused problems before...
Re:Does it cover appropriateness to task? (Score:2)
be quick or be dead (Score:2)
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.
Re:be quick or be dead (Score:2)
Better book idea (Score:4, Insightful)
Just a thought...
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...
Re:Watch your server go up in flames, QUICK! (Score:2)
I suppose under WAMP (as opposed to LAMP) you could shoehorn ODBC into performing "pooling," but, oy vey, I wouldn't wish that on my worst enemy.
Re:Watch your server go up in flames, QUICK! (Score:2)
Re:Watch your server go up in flames, QUICK! (Score:2)
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:Please don't use direct connect (Score:2)
In this case, he's saying write
in dbfuncs.php or something, then using require_once("dbfuncs.php"); $handle=connect_to_the_damn_database(); in all the other files.
This way when your pas
Re:Please don't use direct connect (Score:2)
What PHP really needs (Score:4, Interesting)
Then again, I suppose working namespace support is probably a more pressing concern at this point.
Build a Database Driven Site -- Quick? (Score:2)
RoR is gaining traction (Score:5, Informative)
Re:RoR is gaining traction (Score:2)
If I were to do this... (Score:2)
I'd be more inclined to using Ruby on Rails [onlamp.com].
I was impressed with what I saw when... a lot of bang for very little code.
Do the same thing with 10 Minutes work (Score:3, Insightful)
Save the Adverbs, Quick! (Score:3, Funny)
Four Sample Chapters for this book (Score:2, Informative)
Doesn't everbody know? (Score:2, Funny)
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....)
Re:PEAR? (Score:2)
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:Request for Comments (Score:2, Interesting)
Object oriented data access layers can sometimes be useful - bu
Nice book (Score:2, Interesting)
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, r
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:Using PHP & MySQL to Build a Database Drive (Score:4, Funny)
Re:Database Driven S! (Score:5, Funny)
No