NYCPHP Meetup

[Oktay Altunergil]

You might not know it yet, but you're very lucky :)

I'm kind of in an opposite situation right now, moving away from PHP & MySQL and towards .NET & MS SQL.

I think the question you need to ask yourself is this.

Are they really trying to migrate as much of their stuff as possible to Linux and MySQL? The reason I'm asking is this. If this accounting package will be a standalone system and not need to communicate with other systems, then you might as well do it using ASP and MS SQL. (though I would recommend using PHP anyway, regardless of the database)

If you will need several systems to talk to each other in the future and there's a trend in the company "for various reasons" to migrate to linux, then you should try to consolidate as many of your systems as possible on linux. This will make communication between the systems much easier and your SQL queries much simpler.

As for your questions about whether MySQL can do the job.. .. MySQL has a very simplistic way of doing things. This is not necessarily inferior. Backups and restores are extremely easy to do and there are multiple ways to do it. (SQL dump vs actual data files). IMO, you are all right as long as you take periodic backups and run a stable kernel on your OS. (I recall something about a data corruption issue with some kernels)

Oktay


On Thu, 10 Oct 2002 17:00:02 -0400
Anthony Tanzola <tanzola at rcn.com> wrote:

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