[nycphp-talk] if you were teaching PHP...
1j0lkq002 at sneakemail.com
Mon Jan 17 19:14:23 EST 2005
Hmmm.. snce you asked...
You teach them PHP and then you get to the database concept. So you need to
step outside of PHP and show them MySql by itself (just show them.. that
means you do all the work, they don't need to know it all, but you show
them command line mysql like you were preparing for a dynamic website. All
Then you step out of MySql and *discuss* how PHP can integrate the database
with the website.... call on mysql for data, generate HTMl etc. Still no
PHP-mysql coding, just mysql commands and PHP coding.
Then, since this all makes great sense and they have seen the power of
MySql and understand how HP should be able to automate the crap out of that
commandline process, yu give them a real-world dose of coding mysql in php.
That's manual coding with num_rows and fetches and all. Sur eit's tedious
but it's didactic, and you're the one who chose to be a teacher ;-)
Once it is clear what a PITA this PHP-MySql thing is, suggest that other
dbms/file systems might be better suited. Take a peek at sql lite, php
itself without a db/fs, and hopefully you've made the point that MySql is
nutritious. Maybe mention postgres as that other unwieldy open source one;
jst to be fair ;-)
Now at this point they see that databases are 1.) alot of work 2.) tedious
and repetitive and 3.) essential for many website projects. Your success
will depend on your ability to sow them the vision of a properly integrated
PHP/MySql system...CSS and all. Not always as easy as it sounds.
Only then would I go into PEAR:DB and abstraction. I would approach it via
the concept of abstraction. That way you get to start them on a path
towards writing their own MySql function libraries, since they "know" php.
Now quickly abandon that crazy idea, adopt PEAR based on it's claims and
Dan's evident genious and utmost confidence in it, demonstrate the
commitment required and the platform dependencies (maybe this will
introduce them to the idea of third-party dependencies?), and hopefully
nudge them conceptually towards the concept of interfaces and OOP.
Since it is a first course, this deeper stuff is meant to wet their
appetite -- PHP as advanced such that it really has conquered the practical
issues but the programmer needs to master the concepts in addition to
developing coding skillz. But all of that is not available to every PHP
As it gets deep, be sure to provide practical "but here's what we realy do"
examples. Don't be afraid of coding mysql queries for small projects; don't
get to deep into custom abstraction; don't be afraid of PEAR but understand
what you're getting into when you adopt it; understand how PHP addressed
the core issues with mysqli, available at your nearest $5/month hosting
company any century now; and of course emphasize how separation of data
management from coding from designing from information architecture **FROM
SEO REQUIREMENTS** is so essnetial for anything larger than you local
Phew. Good luck!
From: David Mintz dmintz-at-davidmintz.org |nyphp dev/internal group use|
Date: Mon, 17 Jan 2005 17:34:27 -0500 (EST)
To: talk at lists.nyphp.org
Subject: Re: [nycphp-talk] if you were teaching PHP...
Thanks Mitch, points well taken. My thinking was, this is PHP and MySQL is
immensely popular, so let's show them one native PHP MySQL API and let's
show them PEAR. There isn't time to get into both mysql_xxxx and
mysqli_xxx, so I have to choose one. The former is of course still widely
used, but the latter is the way of the future, or so I assume.
Of course, I try mightily to teach them principles, terminology and
self-teaching skills such as RTFM, so they should be reasonably prepared
to self-teach whatever we don't get into.
On Mon, 17 Jan 2005, Mitch Pirtle wrote:
> Depends on where you want your students to be at the end of the
> course. Do you want them to be limited to writing native mysqli calls,
> or have an understanding of how to use whatever database was
> If the course is on php development, then you should show them how to
> write database independent code, and then show what the cons/pros are
> of writing the apps with the native libraries instead.
> I mean, it is easy to understand how to work with native libraries,
> but the more abstract nuances of using classes is always better
> explained in the flesh, no? Database abstraction is a perfect scenario
> to illustrate the benefits of an OO-based approach.
"Don't let the liberal media tell you what to think
and feel. If you have hatred in your heart, let it out."
-- Clayton Bigsby, black white supremacist
New York PHP Talk
Supporting AMP Technology (Apache/MySQL/PHP)
mail2web - Check your email from the web at
More information about the talk