Slashdot Mirror
PostgreSQL Slammed by PHP Creator
leifbk writes "'The Web is broken and it's all your fault' says Rasmus Lerdorf, the creator of PHP. He talks about not trusting user input, and the brokenness of IE, which is all fine. Then he makes a statement about MySQL vs PostgreSQL: 'If you can fit your problem into what MySQL can handle it's very fast,' Lerdorf said. 'You can gain quite a bit of performance.' For the items that MySQL doesn't handle as well as PostgreSQL, Lerdorf noted that some features can be emulated in PHP itself, and you still end up with a net performance boost. Naturally, the PostgreSQL community is rather unimpressed. One of the more amusing replies: 'I wasn't able to find anything the article worth discussing. If you give up A, C, I, and D, of course you get better performance- just like you can get better performance from a wheel-less Yugo if you slide it down a luge track.'"
If I 'emulate' enough features in the code, I can do away with both packages AND still get a performance boost. Probably. However, the whole point of having a seperate package do it is so I dont have to work more than needed.
The creator of PHP thinks that PHP is #1 and all others are #2 or lower? Shocking.
They say to a man with a hammer, everything looks like a nail. I'm sure it was even worse for the guy who invented the hammer.
Considering that this is coming from the author of one of the worst hack-jobs of a language since Visual Basic, I'm going to have to give his opinions a pass. Pragmatism is great, but even Perl has principles.
I got my Linux laptop at System76.
Why would we listen to the creator of a badly performing broken scripting language about a reliable performance oriented DB?
Not the whole world is interested in rendering HTML tables with blathering text.
The cesspool just got a check and balance.
This guy is an idiot. PHP is a nice product though, if anyone can get past its inconsistent function naming schemes.
He also states:
He *just* learned that? Oh my, that's scary.
MySQL is made for speed compromising to act like a database where it does not break its own convenience. PostgreSQL is a database which will compromise for speed, if it does not break the database.
From someone who obviously is suprised that to secure something you need to make a safe-house and then be strict about what gets in, it seems that he missed the point on the MySQL/PostgreSQL thing.
Maybe by the next conference he'll grow up and state the new revelation "You have to use a database like PostgreSQL and use a warehouse schema to allow faster reporting."
====
Nor was this a "slam". PostgreSQL is not made for specifically web use. If anything, Lerdorf merely publicly demonstrated his own immaturity.
Have you read my journal today?
While people might not agree with me that PHP is horribly broken, I think we can all agree that if we were to choose between Apache, PHP and Postgresql as to what made the web more broken, I think almost everyone would pick PHP. The reason can be summed up as bad design decisions in PHP (slashes, inconsistent naming, header fun, etc.).
I don't blast someone if they choose the smaller learning curve with PHP + Mysql, but they're certainly not the superior solution compared to for example Perl/Python + Postgresql/Oracle.
It takes a man to suffer ignorance and smile
Be yourself no matter what they say
I've used MySQL on several projects. At first because we didn't know any better, later because it was the thing we knew best, or because the project was already using it when I joined it. Inertia. We're using a 5.0.x now, on a setup where we replicate to six slaves, it's not small.
I knew that MySQL could do stupid things now and then, but at least it was our stupid thing. We have some experience with it, by now.
Recently though, some colleagues on another project had an issue with major data loss - an input script had put data into the database that wasn't really compatible with the data model.
Turns out that in a table with an auto-increment primary key named 'id', some of those ids occurred over 200 times. A primary key.
I don't care if there's options or ways to have it check that, even without "emulating it in PHP" (shudder) - anything that is even considering putting "SQL" in its name has to complain loudly when someone tries to insert such crap, and then abort. Not just silently accept it.
That's the eternal problem with MySQL - everywhere, the default action on wrong input is to silently continue, perhaps trying to read the mind of the programmer and turn the nonsensical value into some equally nonsensical default. Put a string into an int field? Let me guess what you meant... etc.
I've had it, I don't want MySQL anymore.
The headline implies that Rasmus blames PostgreSQL for breaking the web which is not the case. The focus of his ire is web application programmers for putting too much trust in user input. I don't think anyone can truthfully argue with that.
His comment regarding PostgreSQL was:
"If you can fit your problem into what MySQL can handle it's very fast, you can gain quite a bit of performance."
As someone who uses both MySQL and PostgreSQL in production environments, I couldn't agree more. The key qualifier is "If you can fit your problem into what MySQL can handle". In order to argue that this statement is wrong you would have to argue that PostgreSQL is faster than MySQL in situations that are ideal for MySQL.
XJS*C4JDBQADN1.NSBN3*2IDNEN*GTUBE-STANDARD-ANTI-U
Recently, I've been using Drupal (PHP CMS system) with a MySQL backend and I am STUNNED, STUNNED I SAY by how productive the combination is compared with, say, ASP.NET and SQL Server. It's a messy, awkward, ambiguous and utterly unscalable language with a cluttered global namespace stuffed full of magic variables and near-identical functions -- combined with a 'database' that simply does not do what a proper database does. And I love it!
...I want PHP and MySQL!
I don't understand this compulsion to prove that PHP and MySQL are good. They're not good. They're sh*t. They're extremely old fashioned and underpowered solutions to problems that are already solved far more effectively in the MS world AND in the OSS world AND even in the proprietary Unix world. Every time I poke around in the Drupal source I have a little smugness session as I think how much clearer and more efficient and more cleanly extendible it could be in C#, or even Java. Then I go right back to using it -- not because it's good, but because for the size of task I'm using it for, it's productive.
Sure, SQL Server is better and so is PostgreSQL, and sure, the antics of LAMP people to prove that PHP and MySQL (and CVS, for that matter) are real grown up systems are laughable. But so what? I'm not trying to be scalable or extensible or secure beyond very narrow parameters that I already know fall within the limited scope of PHP and MySQL. I don't want to use the best tools; I'm familiar with the best tools and the scale of operation they best suit. When I want the following methodology:
GET
gunzip
tar -xvf
vim vim vim
exit
(end of long meandering rant)
Whence? Hence. Whither? Thither.
By the way, the "emualting PostgreSQL features in PHP" part was completely misquoted. I was explaining how MySQL's internal prepare/execute API is rather broken because if you use it you completely miss the query cache, so my suggestion is to turn on prepare/execute emulation in PDO while behind the scenes it will use the faster direct query api calls and thus will also hit the query cache. So this was actually a bit of a MySQL slam which was utterly misquoted. Trying to emulate PostgreSQL things in userspace PHP would be moronic.
So since you stepped in here for some abuse :) don't you think that putting application logic in your program instead of letting the RDBMS handle it makes for a less-maintainable program?
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
FWIW, the commercial database UNIFY used to be pretty much the same thing back in the mid-80s. They had a wicked-fast ISAM database, and then they wrapped that all up in an SQL wrapper. They were a little more concientious, though, so you had guaranteed atomic transactions and rollback capability and more complete SQL support (e.g., nested/correlated subqueries), so it was truly relational (as the term is generally used). Horrible syntax-based optimizer, though (actually, I'm not even convinced it was an optimizer, it was probably just the way their SQL parser interpreted the query).
Just junk food for thought...
Personally, I don't care what it used to be, I care what it is now. And, even if I did, I don't see how either course you describe is worse than the other. They are different development models, and depending on your needs the products will have very different advantages and disadvantages before they converge to both being relatively feature-complete and efficient, but generally neither is worse or better.
If you use it, and it works, and you have people that are more productive maintaining it than some other languages, it is, ipso facto, an "actual useful programming language".
Now, it might lack features that you would find ideal in a perfect world where everyone shared your background and tastes, but that doesn't stop it from being actually useful.
I've reconsidered. I still think you seem to be an insecure language and database elitist with a strong need to feel superior to everyone whose preferences differ from yours, and a deep resentment that your favored tools aren't always the most popular.
I've been writing Perl for 6 years now and I've yet to find a more versatile language.
I've been writing in Perl for 13 years and detest supporting the crap code written by people who think it's applicable to every problem domain.
SQLite.
Why is it that many people who claim to support standards have such atrocious spelling and grammar?
You want ACID...? Use J2EE transactions and Hibernate, and never worry about which database you use again.
Yes. But shit happens. It is always nice to have a relational database that GUARANTEES data integrity. You should not depend on the application for maintaining data integrity - all applications have bugs and you don't want those bugs thrashing your data. You shouldn't completely depend on the framework for transactions - even Websphere has bugs.
Isn't this flamewar old enough for people to start ignoring it? Holy cow: the mySQL vs. postgres argument has been hashed and rehashed so long... isn't about time we realized that neither is a clear all-encompassing winner over the other?
I wish the people writing the news summaries here would tone down their appetite for sensationalism. We all like to have a nice friendly anti Microsoft flamewar-deathmatch every once in a while just for fun but headlines like 'PostgreSQL Slammed by PHP Creator' sound like they were written by a member of the British tabloid press. Can't people voice some criticism without getting gutted any more? And, no, I am not new here I'm just getting a little tired of the fanboyism.
Only to idiots, are orders laws.
-- Henning von Tresckow
You're kidding, right? In this case, Slashdot was directly responsible for distributing the hearsay of hearsay in the first place.
It's pretty routine to have a just plain wrong articles on the front page of Slashdot, and posts pointing out the editor's idiocy buried deep in the comments. It's amazine to me that you think this is a positive thing.
Your data is pretty worthless if you can't be bothered with ACID complience to make sure it is consistant.
PHP through 4.1 was an AWESOME prototyping language... what it was designed for. Back then, you could POST or GET a form, and the variables were automatically filled in. This was a huge security whole, and therefore plugged, which has made it less useful in some ways, but more production friendly in others.
However, my old partner when to a PHP conference, and was STUNNED that the recommended course of action was:
1. Use PHP to prototype
2. Move all business login into C or C++
3. Call the business logic from PHP wrapping the C/C++ calls
While that may be more "correct," that would have massively increased development time.
Our current cycle is like this:
1. Prototype in PHP and PostgreSQL in a test database, treating it like MySQL or Access (a retarded database)
2. Move all validation code into the database with pl/pgSQL, using triggers, etc
3. Performance tune by creating (using triggers) optimized tables for the live site.
4. Deploy
This gets us a lightening fast, reliable system. Unfortunately, for legacy reasons, we have so much PHP code that we've written that migrating to something else (including PHP 5) is hard to justify until we have the budget to get the extra staff just to migrate the system.
It's more work on the DB side, but it's well worth it.
One of the performance tunes we've considered: pl/php, which last time we evaluated it, wasn't quite ready for prime time. Our idea: after tuning your database, move all your database access into the database.
Essentially, for each "page type" on a dynamic site, create a php function that gathers ALL the data you need and puts it into an array. Then, call the Database PHP function getPageType("values to be passed"). The server side PHP function will do all the queries you need, serialize the array, and return it as a TEXT value. Your web page deserializes and displays.
The reason for this is that you have several delays and resource hogs:
1. unoptimized queries: before you move things to stored procedures, test your SQL with explain. Add indexes as needed. If you look up on two or three values, create an index on those values... basic stuff, but will get you massive speed-ups.
2. database connections, to keep this down, put everything on the server into one database and use schemas for access, now you can use persistent connections with a "web" user that connects in persistently and switches as needed (or make your getPage functions accessible to the web user... SECURITY definer, grant execute to the web user).
3. back-and-forth connections: the best way to kill performance, have a PHP script that calls the database, gets some data, calculates on it, and queries again... the fewer queries to the database a page, the better, less overhead. If you need to do back-and-forth activity, write a stored procedure, then there is a single database call. PostgreSQL lets you write stored procedures in SQL, so there is no excuse not to do it.
If you are doing a project of any magnitude, (i.e. 2-3 programmers on it), then one of you should learn to play DBA and optimize the database. If you do that, PostgreSQL is a fast moving beast.
Most performance competitions are MySQL users testing PostgreSQL. However, if you use PostgreSQL like MySQL, it's dog slow. MySQL is a "retarded" database with almost no overhead, so querying the database 15-20 times on a page is harmless. PostgreSQL requires database administration. Once you set up your database right, and tune the server settings (increase buffers, allocate more sort memory, etc.) it screams, but you have to treat it like a real DB.
If you are just throwing your thoughts up on the web, it's not worth it, but if you are doing a real "small" project, where the license for Oracle, DB2, or even MS SQL Server would be extravagant, PostgreSQL is a great option. (The problem with the real databases isn't just the price tag, it's that they are more powerful IF configured right, so you end up needing a 6-figure DBA, instead of a book on database design and about 12 hours to get used to writing triggers).
Alex
which is neither yours nor very good SQL
s istent-read.html
Open-source GPL + optional commercial licensing not good enough for you?
real database
But maybe we don't need a "real" database. Maybe we need an easy-to-use replacement for flat files with some database features. Not everyone is running a bank, or handling a billion emails a day, or tracking inventory for Wal-Mart. Lots of users just want something that can handle their small little application.
IMHO, one of the reasons why the web is broken is that it is so easy to create content that no one takes the time to learn the basic computer science involved
Spoken like a true CS major. CS is a valuable, valuable field - I have nothing but the highest respect for it (which is why I'm getting an ECE degree + CS minor). But the web is not 'broken' - it is the single most valuable informational resource that we have ever created. And the web is useful precisely because you don't have to understand CS to create content. Do you think that there would be 1/1000th of the content on the web if you had to understand CS to contribute to it? No. What we would end up with would be a web that consists entirely of pages created by pencilnecks like yourself and by corporations with big budgets. There would be no Slashdot. There would be no Wikipedia.
In MySQL, the second query would have to wait.
Perhaps you should stop using MyISAM and start using InnoDB:
http://dev.mysql.com/doc/refman/5.0/en/innodb-con
The contributor of this article should be ashamed of his/herself for the sensationalized, misleading title. And - /. mods - you there? Did you read the article before posting this to the front page? Hardly an accurate depiction.
The presentation that Rasmus gave showed some very, very powerful tools for profiling & improving PHP performance. The MySQL/PostgreSQL comment was barely a footnote on a presentation of tools that deserve the positive attention that Rasmus gave them.
"The web is broken and it is all your fault" comment was completely taken out of context. I took it as a challenge to the majority of web developers out there that are ambivalent to security and practices that represent a challenge to our profession. Anybody hear this thing folks are talking about called 'identity theft'? We as web developers have a responsibility to our customers and end users to protect the data they share with us. Rasmus was presenting to improve awareness of both the technical vulnerabilities as well as tools & techniques to address the problems we face. It's a shame that those messages didn't reach the slashdot community.
Seriously, check out the tools that were the focus of Rasmus's presentation: valgrind, callgrind & kcachegrind - they are amazingly powerful.
Basically, they needed to aggregate data from about 56 million rows in table, and required a self-join as well. I got the consulting contract because this was taking at least six days to complete.
Inputting the 56 million records took about a hour; this included creating three indices.
So far so good. At that point, to make in run faster, I wanted to pre-calculate and deformalize the data the self-join would give. I'd already included columns for this denormalized data in the table, so it was pretty much
A simple correlated subquery self-join in a update. Low and behold, MySQL doesn't allow this,. at all:
Ok, so instead of a subquery we can do a join, but that means we have to throw away the max() operation. Without the max predicate we're doing 1-to-Many joins on b where there is more than one row matching our criteria, and so we're potentially doing multiple updates (all but one of which gets "thrown away") to a row.
Ok, so far so good.
First time around, I included the demoralized column in an index, and of course the update changed the column values. If I dropped and re-created the index, MySQL took about four hours to re-index (four times the time it took to make the index when it BCP'd it in). But if I repaired the index, rather than dropping it, well, it never actually completed, becasue after two days I killed it. What the hell?
Finally, to display the data, I needed to do some date manipulation, a lot of it repeated. In pg, I'd have written the code once, in a user defined function. In MySQL, that requires compiling a shared library, so instead I repeated these rather long calculations in a select. Tedious and error prone. (In MySQL's favor, the built-in date functions are a lot cleaner than T-SQL's.)
Eventually I got a six-day or longer process down to three hours, but it wasn't pretty.
So long story short: a business goes with MySQL because it's "fast". At a certain point, it ceases to scale, and you have to perform "heroic measures", denormalizing and pre-calculating. The index repair is a mess. You can't easily encapsulate code in functions or, prior to 5.0, views. It's no longer fast, and your mission critical business requires calling a consultant to optimize what was perfectly good code before the table size grew.
Opinions on the Twiddler2 hand-held keyboard?
Sarcasm or not, I half agree with that.
Today's problem isn't that databases are bad, it's that we use a textual language to interface with databases, and it blurs the line between data and code.
SQL sucks.
As copyright owner of this comment, I authorize everyone to defeat any technological measure which limits access to it.
It's news to me. I haven't seen a recent benchmark that says this, and I'm always skeptical of claims MySQL is faster:
Seriously, if you can prove MySQL is faster for a real-life situation, write a paper, lay all your steps out for review. (Or point me at one someone else has done on modern versions of said databases.) There are lot of potential mistakes in benchmarking, and I won't believe claims unless I actually see that none of them were made.
By the way, what were you saying about Apache header stupidity? The article is annoyingly vague.
RTFA geez. The artitcle was not about postreSQL, it merely mentioned it. He didn't slam it at all or even state that you shouldn't use it. Simply said that if desired you may be able to avoid using it and emulate missing features of mySQL using php. He was illustrating the capabilities of php, not slamming postreSQL. By the way, many hosting providers provide mySQL but not postgreSQL so it may be useful to work around not having it.
Where did the title for this slashdot post come from? The couple sentences that mentioned postreSQL? What about the rest of the article? Stop being drama-queens. Slashdot needs more serious posts- not this flame-inducing crap.
Couldn't be more correct. I've done a little PHP hacking when I'd no other choice--it's to be avoided when possible. For what it was meant for initially, it's not too shabby, but as a general solution it's...lacking.
It's not really surprising that the author of PHP would think that the things PostgreSQL buys you aren't worth it. You know, little things like integrity, reliability and stability. Who needs those? Not anyone writing in PHP, certainly.
Sure thing. Did you say this?
If you don't like insecurity due to poor input handling, why did you design your language to encourage it? magic-quotes-gpc is the worst language feature I have ever seen. It manipulates one particular set of inputs to make them conform to one set of output which doesn't always apply but is always a bad idea. People should be using bind variables supplied by the database library, not quoting according to MySQL x.x's rules and then sticking things directly into their statements. This is like a giant neon sign called "Security" pointing in the opposite direction from the real thing.
In contrast, Perl has taint mode, a feature you'd do well to emulate. It actually tracks a flag on each variable seeing if it came, directly or indirectly, from untrusted input. If so, it must be untainted before being used in any of a number of security-related situations. It's smart enough to avoid requiring any way of doing so which is probably inappropriate. It just flags things which are almost certainly wrong. Actual thought needs to go into correcting them, and as users learn the situations taint mode complains about, they trip it less and less often. Correct taint-mode code runs the same with it off, which makes it much superior to magic-quotes-gpc.
Nah, you're just too insecure to admit that there are actually ways to rank the functionality of these things. MySQL is good specifically in situations where you're going to do a lot of simple transactions on fairly simple data. That it's superior in that one, very narrow, situation, however, does not make it superior as an RDBMS or even equal to other software in the category.
Likewise: PHP. PHP is an inferior programming language and that's that. It's good at RAD and it has a very gentle learning curve. That's it. That's all it's good at. Perl is a better language. C is a better language yet. That PHP is good in one narrow field does not make it superior or even equal in its category.
It's really not that complicated of a concept. If you have two quarterbacks and one can throw the ball 75 yards consistently but can rarely get the ball anywhere near his receiver beyond five yards, he's very good at doing one particular thing, but he's still an inferior quarterback. That you get him out when you need an undirected hail mary does not make him an equal to the guy that carried the rest of the game.
Contrary to what some people would like to believe, not everything is equal just because it does certain things well that other products do on a more average scale.
The creators of PHP are morons, and their support company Zend is dishonest and incompetent. The ZActiveRecord boondoggle demonstrates exactly what I mean: They can't program their way out of a paper bag, an don't even understand the limitations of the very language that they haphazardly "designed".
It makes me laugh that Lerdorf would slam Postgres, because the PHP designers have no understanding of object oriented programming or databases: instead they invent half baked cargo-cult designs, which are naive reactions to other systems they don't understand: they try to ape their surface features without understanding the reasons behind the way they're designed.
PHP references were thrown in as a band-aid to work around the horrible design flaw that arrays and objects were foolishly DEEP COPIED by default. If you pass or return an array from function to function, its contents are DEEP COPIED, which is EXTREMELY inefficient and leads to all kinds of horrible bugs because it's the last thing a sane programmer would expect. So instead of fixing the design flaw in PHP, they add "references" that LOOK and SOUND like C++ references, but actually are completely different, again misleading programmers into thinking they understand what's going on, but working totally differently than a sane person would expect. PHP references are actually half baked symbol table references. The sloppy implementation caused many bugs that CORE DUMP PHP! PHP references were so poorly thought out and badly designed, that there were many edge conditions that they hadn't considered, that simply didn't work together, caused memory leaks and core dumps, and had useless and confusing semantics: callers passing references, functions declaring that they take references, functions returning references, etc. Compare that to C++'s simple and consistent definition of references in term of pointers. The only way to make a PHP reference to an object is to put it in a variable -- you can't make a reference to a field of an object or the return value of a function without storing it in a temporary variable -- totally unlike C++, and totally stupid.
PHP's object oriented programming system is a half-baked imitation of C++'s object model, haphazardly designed by charlitans who had no clue about the fundamentals of object oriented programming, elegant language design or efficient implementation. First of all, if you're going to try to imitate an existing design without understanding it, then for god's sake, at least imitate a language whose object system doesn't suck, and a language that has similar semantics to the language you're trying to kludge. C++ is a static compiled language, and its object system deeply reflects that fact. (That is to say, there's very little reflection beyond RTTI, because the compiler throws all the interesting stuff away! And C++'s oop design had to make many horrible compromises because the C++ object system was designed to map directly into C semantics [since the original C++ compiler compiled C++ into C.]) Most of those C++ design decisions make absolutely no sense for a dynamic interpreted language like PHP. (Many of them made very little sense for C++ itself, but even less sense in the context off PHP.)
One prime example of how PHP screwed up its object system, is that they blew it on static methods, in a way that makes it impossible to properly implement an ActiveRecord-like ORM (among other us
Take a look and feel free: http://www.PieMenu.com
Okay...so is that what you were talking about here?
If so, why are you complaining about something that has no significance? If not, what are you talking about?
"magic quotes" was, is and will forever be a terrible idea.
It is one of the many PHP misfeatures that make it easy for programmers to do the WRONG THING.
The correct way to do things is to filter/quote inputs to your program accordingly so that your program can handle them correctly.
Then you filter/quote outputs from your program to other programs accordingly so that those programs can handle the outputs correctly.
If you don't do that you will end up with corrupted or misinterpreted data or worse.
The correct filtering/quoting for an Oracle database is different from that for MySQL, and is different for a web browser, and for syslog.
Magic quotes combines all the quoting with one "easy" "fix", and because of this sort of wrong-minded thinking, plenty of sites are littered with spurious backslashes in their content.
There are plenty of other things PHP does wrong, and a lot of those are PHPisms - the things that make PHP PHP. By the time they fix those, PHP ends up not like PHP. Go look at the "backtracking" changes from PHP3 to PHP5.
You might as well skip all that crap and go with some other programming language - like python, perl, ruby.
BTW the same goes for MySQL, look at the changes from MySQL3 to MySQL5. MySQL3 = "Oh you don't really need transactions at all". MySQL4, "use transactions if you don't need speed". MySQL5 "oh yeah quietly corrupting data by default is a bad idea after all".
With PHP/MySQL 3 to 5, if you leave the defaults on, lots of things break, because the old way of doing things was a bad idea e.g. register_globals=on.
With Postgresql, the direction and principles have remained pretty much the same over the years- just getting better and better. So if you have written a program for postgresql 6.5, you can pretty much upgrade to 8.1 and your app will usually work by _default_ and work faster too.
You mean like when they supported Windows 98 up until July 11, 2006?
no comment