NYCPHP Meetup

[chalu]

MYSQL can handle your load. Consider NOLA and it was originally 
developed for Becktel, one of the largest public construction company.

As someone mentioned, INNODB deals with some of these issues. It should 
be fine. We have done MYSQL support and PG support as well as commercial 
DBs.  It is pretty solid. Only times I saw problems are operator errors 
and having millions of rows and disk filling up.

Some web analytics engine we worked with.

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


-- 
Chalu Kim
eGENIUS 
20 Jay Street, 1002
Brooklyn, New York 11201
chalu at egenius.com
(718) 858-0142
(718) 858-2434 FAX
www.egenius.com