NYCPHP Meetup

[Kyle Tuskey]

David,

MySQL lacks in quite a few areas.

1) It has poor performance under heavy loads
2) It lacks key functionality
3) Data integrity is currently a big problem
4) Large amounts of data are handled poorly
5) It lacks replication and other enterprise level features
6) Backup and recovery features could use improvement

Just use MySQL for a while and try to do anything like a join on more
than two tables.  It chokes.  Other databases are built to handle real
and heavy processing, whereas MySQL is built for smaller needs.  Some
will argue the de-normalizing data is always the way to go anyway, but
unless you are data warehousing there is no need to do it.  It just
creates poor database design.  You might be able to get away with using
MySQL on some heavier projects, but that doesn't make it the right tool
for the job.  As for your enterprise question, I classify enterprise
level as an application (this is not limited to web applications) that
is currently or possibly going to be under heavy load and needs to be
distributed over multiple machines effectively.  The application needs
to be scalable to decrease the risk of poor application performance with
increasing loads.  As I said this is often misclassified because people
throw the word around without cause.  Most applications don't have
enterprise needs, which makes PHP a great choice for development.



Kyle



-----Original Message-----
From: David Sklar [mailto:sklar at sklar.com] 
Sent: Thursday, October 10, 2002 10:26 AM
To: NYPHP Talk
Subject: RE: [nycphp-talk] Scaling LAMP Architecture

> From: Kyle Tuskey [mailto:ktuskey at exostream.com]
> Sent: Thursday, October 10, 2002 12:20 AM
>
> You can scale LAMP (minus MySQL which is barely a database) to some
> degree, but it isn't really the best way to approach it.  PHP was not
> built to be an enterprise language.  The lack of the N-Tier model
makes
> it great for most sites, but true enterprise level needs would be
better
> approached with J2EE or .Net.  Using .Net or J2EE (Java) will make the
> final solution much easier to use, manage, scale, and deploy.  Though
> the word "enterprise" is thrown around too much and often isn't used
> accurately, applications that truly are enterprise do need to take
into
> account a lot of the advantages of the N-Tier model.  PHP has XML-RPC
to
> all remote calls in a distributed architecture if I remember
correctly,
> but it isn't very efficient.  For instance, Java's RMI (Remote Method
> Invocation) implementation is much more robust for this purpose.  If
you
> must use PHP for an enterprise solution, use a strong RDBMS (MySQL is
> definitely not in this category) and some form of load balancing or
> clustering as opposed to an attempted distributed architecture w/ PHP.

So, Kyle, what is "true enterprise level," then? A billion pageviews per
month? The 800B PV/month Ophir cited at CCI works out to about
300/second,
and I presume that doesn't include images or other static objects.

Tell me, where is the point that MySQL breaks down? Traffic?
Functionality?
I admit, MySQL doesn't have, say, the World's Greatest parallel
hot-failover
technology, but I don't think anyone would classify Oracle's efforts in
this
regard in that way either.

Don't get me wrong, I'm all for using the right tool for the job, and
MySQL
or PHP or Linux or Apache aren't each the right tool for every job. But
if
you're going to insist that PHP or MySQL has problems, please point out
actual problems, instead of vague assertions.

Thanks,

David



--- Unsubscribe at http://nyphp.org/list ---