NYCPHP Meetup

[Larry Chuon]

Anthony,

How far have you gotten with your development process on the accounting
program?  My team did a lot of works on NOLA (web-based accounting or ERP).
If you want, you can take our newly modified version and see if it suite
your environment.  It's an open-source app.  We might be to co-develop some
new functionality for free.  Let me know if you're interested.

Larry


-----Original Message-----
From: Anthony Tanzola [mailto:tanzola at rcn.com]
Sent: Thursday, October 10, 2002 5:00 PM
To: NYPHP Talk
Subject: RE: [nycphp-talk] Scaling LAMP Architecture

Greetings!

I have just joined the list and find this topic interesting.  I am a VB/ASP
programmer and have to this point used both in conjunction with MS SQL
Server 7 with successful results.

My company has asked me to develop an accounting package for them and once
it done using CGI or PHP and MySQL (despite the fact that we own a full
license to MS SQL Server) as they are migrating from Microsoft to Linux for
various reasons.

I have many hesitations using MySQL as a back end for an accounting program.
Access to the database will be at a maximum of 3 people at any given time,
so server load should not be too heavy.  Eventually I may have 20 people
connecting to an orders database tied in.

So my question is, aside from the small user loads and performance related
issues, is MySQL reliable for handling such critical accounting data?

Things that scare me are lack of referential integrity, lack of
transactions, backup and recovery.

Any thoughts would be appreciated.

Anthony



-----Original Message-----
From: Kyle Tuskey [mailto:ktuskey at exostream.com]
Sent: Thursday, October 10, 2002 12:36 PM
To: NYPHP Talk
Subject: RE: [nycphp-talk] Scaling LAMP Architecture


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