[KLUG Members] database programming question

bill bill at billtron.com
Tue Jun 22 14:41:25 EDT 2004


On Tue, 2004-06-22 at 13:42, Bruce Smith wrote:


> > I guess the third reason is more subjective.  I'd bet that once MySQL is
> > running, the website will have more input from its contributors.  I feel
> > almost sheepish in noting that the lack of MySQL may have contributed to
> > the lack of interactivity on the site.  MySQL's ease of use means people
> > actually get brave enough to do things.  Hey, I'll even volunteer to do
> > the first membership sign-up form.
> 
> I'm sure it's technically possible to add MySQL to the KLUG server, but
> there are some concerns.
> 
> First the KLUG server is already running Postgresql.  I wouldn't doubt
> that MySQL would run at the same time, except the KLUG server is old,
> slow, and has limited memory.

Won't know how it affects it unless we try.

> Second, the KLUG server already has a lot of information stored in
> Postgresql.  All the meeting/presenter info, supporting member info,
> library info, and probably more.  It would seem like there would be an
> advantage of keeping everything all in the same database for ease of
> retrieval and use.

That's a similar argument people use to stay with MS instead of
switching to Linux.  In any case, I'm not saying you need to do anything
to your Postgres stuff.

> Third, the OpenGroupware server is using Postgresql, which we're talking
> about integrating with the web server.

Can't help with that.  I don't even know what that means.

> I'm sure either Postgresql and MySQL would do the job on the KLUG server
> equally well, BUT is it worth the effort convert everything from PG to
> MySQL?  What would that gain us?  (other than your subjective reason).

I'm not arguing to convert data.  My subjective reason produces
objective results.  The proof's in the pudding.  I'm arguing that not
using MySQL results in less development, fewer working programs.  The
KLUG website seems to make my case.  I'm also arguing that using MySQL
results in more development, more working programs.  I think the
popularity of MySQL on websites makes my case there too.

If it helps to understand my position, it is not that I love MySQL, it
is that I'm in favor of more working programs for people.  In my
experience, and apparently thousands others using it on the web, that's
true.

> Also, can you explain why the advantages of LAMP over using PG?  Is PHP
> easier?  

I'm a bit confused here.  I think you mean the difference between LAMP
and LAPP.  Although I've never heard it referred to that way.  LAMP is
Linux, Apache, Mysql, and PHP.  LAPP would be (I'm making this acronym
up) Linux, Apache, PostGres, and PHP.  So both would be using PHP.

PHP rocks.  There's nothing like it for web development.  I almost feel
sad for those who don't use it because they have to work so much harder
to accomplish the same thing.  Often they work harder than I do and
still can't make it work.

> The "select" statements are basically the same, aren't they? 

The select statement is almost always the same as they're both SQL
(Structured Query Language), a standardized way of querying dbs.

A select statement may look identical:

$sql="SELECT * from sometable WHERE id=27";

// means select everything in the row from a table named sometable 
// where the field called id is equal to 27.

$result=mysql_query($sql);

//or 

$result=pg_query($sql);

All of these are PHP statements.


> What is else is the difference other than changing the PHP calls from 
> pg-connect/pg-select to mysql-connect/mysql-select? (or whatever)
> 
>  - BS

Practically speaking you need 

1. to have an efficient method of checking and handling errors (the web
guarantees you'll have untrained people doing weird things, you need to
catch all these).

On my websites, for example, I'm immediately notified by e-mail (as I
refuse to wear a pager) whenever a db error occurs.  The e-mail contains
the error and description from the RDBMS, when it happened, what page it
was on, who was doing it, what they're IP address is, what shoe size
they wear, plus a boatload of other current information (variables) and
settings on the server.  That way I can often find the problem and fix
it before they leave the site.

2. a method to parse or pull out the results.

For the above statement, for example, after running the query, I'd be
running another mysql related statement.

$row=mysql_fetch_array($result);

>From there, I'd assign values.

$name=$row["name"];
$title=$row["title"];
$address=$row["address"];  // etc, etc.

3. an easy method of creating, modifying, and managing tables. 
PhpMyAdmin does this astonishingly well.  I think that MySQL here really
separates itself from PostGres.  When I discovered years ago that
PostGres wanted me to -recreate and repopulate- a table to make a simple
modification, I left and haven't looked back.  I hear they can do that
now, but there's no reason to return yet.

Practically speaking, once a MySQL database is created with a couple of
logons, I can put up PHPMyAdmin and run major websites without ever
again using a shell.  That's ease of use.

Hope this is helpful.  

Convinced yet?

kind regards,

bill




More information about the Members mailing list