Big sites

fernandodonster

Could you tell URL of bank sites which developed with php/mysql ?

coldwerturkey

what?

rulian

Well I think a good bank site will hide that fact.
Odds are banks dont run on MySQL, their "email us" database on their website why not but account & activity will most certainly run on much more secure and redundant systems.

Also, i havent seen many but most run on proprietary software, like bank of america extensions are .do which means purposefully trying to hide it's development platform and either via CGI or .NET it can be virtually any language which would be more likely the case

NogDog

While I think MySQL could be configured to be "secure and redundant" (InnoDB storage engine running transactions, using the Replication feature, etc.), and we all know that PHP could do the job, I suspect the vast majority (if not all) banks in the USA purchase their solutions from major IT vendors and/or in-house IT departments that likely use more commercial and proprietary solutions: Java, C++/# or .NET with Oracle or MSSQL for the DBMS.

Again, I'd need convincing that PHP/MySQL could not do the job, but I would not need convincing that the "suits" who make those decisions in the financial sector would be much more likely to buy from IBM/Sun/M$ than use some open-source product created by a bunch of weird geeks who would create a useful product and then -- shudder! -- provide it free of charge.

Sxooter

Most banks likely subscribe to the misplaced belief that obscurity improves security.

As far as MySQL handling banking applications, I doubt it can scale that highly. I'm a pgsql guy, and I'm pretty sure it would have problems scaling that high as well. We're not talking dozens or hundreds of users at a time, but thousands upon thousands. Scaling up to those levels of usage while ensuring that you don't drop a 100th of a penny anywhere is another kind of application altogeher (chorus: it's another kind of application...)

MySQL's default behaviours would be very bad for an accounting database. It's tendency to just lop off parts of a value that don't fit, no check constraints, accepting column level FK syntax while ignoring it, allowing FKs from / to non-transactional tables, and tendency of replication to fail for various reasons with no obvious outward signs can all be worked around, but honestly there are far better choices for databases out there. Ones that don't require startup switches and carefully crafted DDL to make sure your foreign keys, check constraints, and input values actually work the way you'd expect it to.

MySQL is fine for holding non-critical numerical data, but honestly, if you're doing accounting on it, you're doing yourself a disservice using a tool poorly suited to the job.