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.'"

I love my Yugo luge commute

It's very fast and I haven't been killed yet.

Re:I love my Yugo luge commute

Your data is pretty worthless if you can't be bothered with ACID complience to make sure it is consistant.

Re:I love my Yugo luge commute

Your data is pretty worthless if you can't be bothered with ACID complience to make sure it is consistant.

For the last 10 years, MySQL data has been atomic across single transactions.

For the last 5 years, MySQL data has been atomic across transactions.

For the last 2-3 years, MySQL has supported the full gammut of ACID features.

Can we PLEASE stop beating this particular dead horse?

The MySQL 5.0 FAQ [mysql.com]

MySQL still lacks many of the high-level features of databases like Oracle, and for that many of us, the USERS of MySQL are generally greatful.

Not a great idea at all.

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

Re:I love my Yugo luge commute

The luge isn't something you just dump Yugos on, it's a series of tubes!

Avoid databases...

<Sarcasm>Honestly, just avoid this discussion by using flat files.</Sarcasm>

Re:Avoid databases...

You kids and your fancy flat files. Back in my day, we kept our data in huge honking boxes of punchcards, and we were grateful!

Re:Avoid databases...

You had boxes?

Re:Avoid databases...

We were supposed to keep that stuff?

Re:Avoid databases...

You had stuff?

Re:Avoid databases...

You had?

Re:Avoid databases...

Back in my day, we no fancy verbs! And we it!

Re:Avoid databases...

You it?

Maybe this too far...

Re:Avoid databases...

You had paper? We recorded everything on slabs of rock.

...When the system crashed, you knew it crashed. That's how we lost Ug, we really miss Ug.

Re:Avoid databases...

Pfft. I was a sysadmin for the Tower of Babel. When that thing divided by zero, man, nobody could even talk anymore.

Re:Avoid databases...

Just be glad that you missed the 40 day and night core dump. Boostrapping a planet takes forever and they hadn't invented overtime yet.

Re:Avoid databases...

40 days would have been a vacation for us. We had to muck about for 40 years just trying to get the rain server going. For years it just rained bread, and the Manna pages were completely useless.

Re:Avoid databases...

Why, we used to DREAM of boxes and punchcards! In MY day we had to line up large stones into neat rows to represent binary. On a steep slope. In the middle of an earthquake. In Antarctica.

Re:Avoid databases...

You had binary? We had to get about with only zeros, and some days we didn't even have those!

Re:Avoid databases...

We only had ones because the zeros were too fat to fit through our tiny wires.

Re:Avoid databases...

And the lord said, "Let there be light!" And Moses, who was the chief electrician at the time, pulled the switch, blew the fuse, and fucked up the entire miriacle ........

One word:

SQLite.

Re:Avoid databases...

Would you prefer to have the patchwork system that made itself into a DBMS at some point after it's wide adoption, or the one that started out a relatively proper system and then just tweaked things to get performance gains?

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.

Regarding PHP: it's okay for moderate tasks and I use it, but I only use it because nobody else who's likely to maintain my code in the future seems to know any actual useful programming languages.

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.

And if you think I'm a database and language elitist, you might want to reconsider your position: am I an elitist, or are you (not the OP, you the reader) just poorly informed about the underlying concepts of these two things?

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.

Re:Avoid databases...

Nah, you're just too insecure to admit that there are actually ways to rank the functionality of these things.

No, I've admitted that, several times, in this thread.

There are many ways to rank the functionality of things, not one correct way.

MySQL is good specifically in situations where you're going to do a lot of simple transactions on fairly simple data.

Which is, in fact, what a lot of web applications on LAMP infrastructure do.

That it's superior in that one, very narrow, situation, however, does not make it superior as an RDBMS

"Superior as an RDBMS" is mostly a meaningless, or at least equivocal and ambiguous, category.

or even equal to other software in the category.

Sure, in the sense that "different" is not "equal".

Likewise: PHP. PHP is an inferior programming language and that's that.

"Inferior programming language" is meaningless.

It's good at RAD and it has a very gentle learning curve.

And, in that, it is superior to languages that lack those features for uses where those are key features. Making it not unqualifiedly an "inferior programming language". Its like saying "A hammer is an inferior tool. It's good at driving nails, and that's it."

Perl is a better language. C is a better language yet.

There are certainly things for which C is better than Perl, and certainly there are things for which Perl is better than C. Your standard for saying that C is in some trascendent, unqualified sense "better...yet" compared to Perl is...what?

That PHP is good in one narrow field does not make it superior or even equal in its category.

True, again, because "superior" in the nonspecific sense you are using it is meaningless and, therefore, nothing could make anything superior in that sense.

It's really not that complicated of a concept.

It isn't a matter of complicated. It is a matter of wrong.

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.

Really? If the other one can consistently hit a receiver out to 80 yards, but almost always fumbles the snap, I'm not sure if I could agree that the one you describe is "still an inferior quarterback": you can't label something inferior to something else when you describe the features of only one of the two things being compared. Further, the function of a quarterback on a football team is much more narrowly defined than that of a programming language or data storage solution, so it makes a lot more sense to talk about an inferior quarterback than an inferior programming language or datastore, without reference to a use for the latter.

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.

I don't know what "some people" you are talking about, but I've never said "everything is equal". I would say that ranking tools without reference to application is generally meaningless except in the narrow case where the ranking holds without exception for all conceivable, or at least realistic, tasks.

Re:Avoid databases...

Amazingly this actually seems to be the approach lots of "Web 2.0" companies are taking. See Tim O'Reilly's database war stories series [oreilly.com] for details.

Some quotes from that series:

• Gabe Rivera of Memeorandum.com: "I didn't bother with databases because I didn't need the added complexity... I maintain the full text and metadata for thousands of articles and blog posts in core. Tech.memeorandum occupies about 600M of core. Not huge." [full story [oreilly.com]]
• Mark Fletcher of Bloglines: "[T]raditional database systems were not appropriate (or at least the best fit) for large parts of our system." [full story [oreilly.com]]
• Greg Linden of Findory: "We make thousands of random accesses to this read-only data on each page serve; Berkeley DB offers the performance necessary to be able to still serve our personalized pages rapidly under this load." [full story [oreilly.com]]

The "databases cause more problems than they solve" sentiment was so pronounced in O'Reilly's interviews that he took the question to Brian Aker of MySQL [oreilly.com] for rebuttal, but ended up concluding that

I didn't hear that flat files don't scale. What I heard is that some very big sites are saying that traditional databases don't scale, and that the evolution isn't from flat files to SQL databases, but from flat files to sophisticated custom file systems. Brian acknowledges that SQL vendors haven't solved the problem, but doesn't seem to think that anyone else has either.

So...

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.

Re:So...

Not entirely true true. The main point is to have your database contain known-good data. And not lose it. (Yes, you can boost PostgreSQL's performance by turning off fsync but most people are bright enough not to do this.)

Ensuring data integrity requires a well thought-out design of table structures, primary/foreign keys, rules, triggers, etc. It also requires a database server that actually provides the tools required to implement your plan.

Maybe Mr. PHP hasn't heard of Perl, Python, C, Java, Ruby and so on and thinks that databases are only accessed via PHP code written by careful talented programmers eager to reinvent database features. Maybe he doesn't think that people use ad-hoc tools like psql or PgAdmin. Sure, it's possible to re-implement some of the safeguards inherent in a good database design running on good database software. But only for that one piece of code.

It's kind of like a homeowner who carefully installs one new energy efficient window, leaves all the others open, and then wonders why the heating bill is so high.

There ARE other scriping languages besides PHP ...

"Rasmus Lerdorf, the creator of PHP ... said the current state of the Internet includes a litany of broken items, but with a little help from PHP there may well be some hope for the Web yet."

I wonder if he has ever consider using Perl ...

Re:There ARE other scriping languages besides PHP

I've been writing Perl for 6 years now and I've yet to find a more versatile language. I just started working in PHP, and it's Perl-like enough that learning it has been easy. But some things are just not done elegantly, and one has to wonder why that is, given that PHP is in fact pretty good as languages go.

Re:There ARE other scriping languages besides PHP

PHP/FI was the second version, and it wasn't written in Perl. Neither was the first version. The first version of PHP replaced some Perl code which may be where this myth comes from.

Let me be the first to say...

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.

Re:Let me be the first to say...

But with PHP and MySQL, you can hammer screws much faster! :D

wow

he's quite full of himself, isn't he?

the web is "broken" independant of the language used. bad/inexperienced developers are causing the problems, no matter what language is used. in order to not shoot yourself in the foot, you have to know that you're holding a gun and that pointing it at your foot and pulling the trigger are bad things to do.

and mysql and postgresql are different. they both have strengths and weaknesses. you can hammer in a screw faster than using a screwdriver, but thats not the friggin point of it.

Validating Input vs. Inexperienced Developers

"You don't know that you have to filter user input," Lerdorf exclaimed.
Lerdorf advised PHP developers that nothing that comes across the wire is to be trusted.

It shouldn't be necessary to say that, but unfortunately it is. When I took Computer Science 100 in college 30+ years ago, the first lesson about inputting data was that you have to validate it before using it, because it's guaranteed that your program *will* be given bad data sometimes, and will occasionally be given maliciously bad data, and part of the grading process on programs was to run them on the professor's data set, which was malicious, especially at testing off-by-one errors and other boundary conditions. But enough other people didn't get that as part of their education, either in school or learning it the hard way in practice - sigh.

Considering the source

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.

Depends what you are doing...

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

And We'd listen to the creator of PHP

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.

Moo

FTA:

"The Web is pretty much broken, we can all go home now," Lerdorf said somewhat sarcastically to the capacity crowd. "Luckily most people don't realize that it's broken."

Header "stupidity," as Lerdorf referred to it in Apache HTTP Web server, can also be the root cause for the broken Web.

"IE is completely broken in so many ways," Lerdorf said.

This guy is an idiot. PHP is a nice product though, if anyone can get past its inconsistent function naming schemes.

He also states:

"You have to filter everything and then poke a few holes to let things through, "Lerdorf advised.

He *just* learned that? Oh my, that's scary.

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

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.

Re:Moo

Wow I didn't get that at all. Yeah the writer of the article tried to slant it that way but thats just a typical journalist trying to sensationalise an otherwise boring story.

First of all he was pointing out that its a mistake to trust any data from the client. Pretty obvious, but there are a lot of sites that ignore this. He didn't "just learn that", he is pointing that a lot of developers haven't learned it yet. And unfortunately this is all too true.

You yourself admit "MySQL is made for speed compromising to act like a database" and that is exactly what he is saying too. See, if you're web app doesn't require a full featured database, ie. "If you can fit your problem into what MySQL can handle", then Mysql is a good choice for performance reasons. And even if there's one or two features you need that Mysql doesn't support, then you can do a few hacks to make it work anyway and still be ahead performance-wise.

Nor was this a "slam". PostgreSQL is not made for specifically web use. If anything, Lerdorf merely publicly demonstrated his own immaturity.

I don't think he was intending to slam PostreSQL. He was only saying that MySQL has better performance for web apps than PostGreSQL, which you seem to agree with. He didn't say MySQL is better than PostgreSQL, he just said it gives better performance for web apps, and even added the caveat "If you can fit your problem into [it]".

What he is really talking about is the classic problem of elegance vs. performance, a dilemma programmers constantly have to grapple with. Postgres is more elegant, but Mysql has better performance in its niche.

The writer sensationalised it all a bit and then slashdot turned it into a troll. A mature reader would see through that and pay close attention to things actually between quotes, the things the dude actually said.

Rather incomplete quote

You are basing this on a rather incomplete account of my actual talk. I went through a series of optimizations of a sample Web application, and one of many steps was to try MySQL instead of PostgreSQL for that particular application. By profiling it with Callgrind it was obvious that in this particular case MySQL was significantly faster. I don't think this is news to anybody that MySQL is quicker at connecting and issueing simple queries, and I am not sure why me showing some Callgrind profiles and stating that MySQL is particular good at these things is frontpage slashdot material. Slow day?

And the "The Web is broken and it is all your fault" thing was just a bit of humour to wake people up for this 9am talk, but I guess it makes for good headlines.

Re:Rather incomplete quote

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.

Re:Rather incomplete quote

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.

Re:Rather incomplete quote

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.

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.

Re:Rather incomplete quote

It is getting to be rather annoying. A quick email asking me whether the article was an accurate representation of what I actually said would certainly have been more useful, but instead the poster chose to go the other way and focus on the misquoted bits of the article. I have been doing this stuff a long time and have been slammed on /. countless times, but please, slam me for things I actually said or did.

Re:Rather incomplete quote

Sure, the more you can offload to the database, the better. Like I said, my point about emulating things in PHP was directed at MySQL's broken query cache implementation when using the prepare/execute API.

Re:Rather incomplete quote

Once again, I never said it was a good idea to "code around the features of PostgreSQL". I didn't write the article. I gave a talk at a conference. Someone was in the audience taking rather bad notes apparently, and he posted these notes as an article. What I showed was that if your problem fits what MySQL is good at, there are significant performance benefits from using it. It wasn't a PostgreSQL slam in any way. It was a "profile and choose the best and fastest tool for the job" statement.

Re:Rather incomplete quote

I went through a series of optimizations of a sample Web application, and one of many steps was to try MySQL instead of PostgreSQL for that particular application. By profiling it with Callgrind it was obvious that in this particular case MySQL was significantly faster. I don't think this is news to anybody that MySQL is quicker at connecting and issueing simple queries

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:

• Were you using MySQL as an ACID database? I.e., all tables using a transaction table type, fdatasync() on, real tests [livejournal.com] telling you that durability is actually working? If not, either run it properly or run PostgreSQL in stupid mode for something approaching an apples-to-apples comparison. fsync = off in $PGDATA/postgresql.conf.
• Were you using MySQL's query cache? Turn it off. It shows bigger numbers on some bad benchmarks but doesn't help real situations: artificially claims silly numbers for tiny sets (are your real data as small as your benchmark?), cleared after every DML statement on that table, etc.
• For that matter, did you issue any DML statements at all? As the bullet point above mentions, they have much greater impact on performance than their proportion would suggest. For other reasons, too. Doesn't MySQL still just have table-level locks? PostgreSQL's the other extreme; it has MVCC.

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.

Re:Rather incomplete quote

That was a reference to the Expect header problem in Apache that was recently fixed and that not all the problems can be blamed on IE.

And yes, I do know my way around PostgreSQL. It's a good database, but no matter how you tweak it, it still has more connection overhead than MySQL does. And as I explained, I wasn't actually using the query cache in MySQL in the initial steps in this iterative optimization because MySQL's query cache doesn't kick in for prepare/execute queries. This isn't a PostgreSQL slam, it is simply pointing out that people should benchmark and profile their actual applications and understand the costs.

Re:Rather incomplete quote

You are right, you were quoted out of context on at least a couple of things. And you probably had some insightful things to say, so I'm just going to use this as an excuse to rant:

What I find especially annoying is that it seems that the Web is more broken because of PHP than in spite of it. Valid to wake people up to a 9am talk -- when you're presenting Ruby to a PHP conference.

My own personal gripes are:

• While it's possible to call $self->method() from a method (or maybe that's $this->method?), if your function is called as a static class method, it has no way I've found of discovering what class it's in. Yet, you're forced to call static class methods as MyClass::Method. This defeats the main purpose of using a class as a namespace -- you still end up with your namespace referred to throughout the code, meaning you still have to use grep to change it, which can be unreliable.
• The syntax, in general, is clumsy at best. It basically feels more or less like any other C-like language. But this is web programming. I thought we were taking a speed hit to make things easier. I like Perl, Python, and Ruby for tons of syntactic sugar that PHP never had. preg_match is definitely clumsy when compared to =~.
• In order to access a global variable, I must have a line that says "global $variable". Forcing people to declare a variable is good, it means you'll probably notice your typos. If you're declaring a variable anyway, it saves a lot of typing, especially if you're using lots of tiny functions, to do this the Perl way -- say "my $variable" if you want it to be local, and just say "$variable" if you want it to check for a global one first.
• Prefixing every variable with a $ doesn't seem to serve any real purpose. Ok, so I can have a variable called $variable and a function called "function". I could do that anyway. It means you don't have to define variables to use them -- same with Ruby, except Ruby doesn't use prefixes. Perl uses prefixes, but it also uses them for interpolation in strings -- I don't think PHP can do that. Ruby manages that interpolation without prefixing variables except when they're in a string.
• Not a lot of scope choices. In fact, there seems to only be method scope and global scope, and maybe loop scope (foreach and friends), unless I'm missing something. What I miss is easy access to, say, class scope and object scope.
• A history of being seen as the easiest language for web programming, to where now many think "web backend programming" is always PHP, means you have lots of clueless newbie web programmers. The advantage of PHP was being easy to learn and having some nice features for web programming, but many of these (register_globals, anyone?) have been found to be security flaws, and are no longer reasons to use it. Yet, and I know this isn't your fault, given the choice between a PHP app and a Python|Perl|Ruby|C|ASP app, I won't choose PHP, because PHP developers tend to be the ones who say "If our app gives you security errors, just chmod 777..."

To be fair, I have found some advantages:

• Easy insertion of HTML code. This is nice for developing an app quickly. I still don't find it too incredibly useful in larger apps, though, because it makes more sense to split most of the HTML out into a separate file, and generate the rest, maybe even through some XML API.
• Powerful templates. Being able to embed real code into a mostly HTML template is a beautiful thing. And yet, I find myself both wishing it was a more powerful language, and thinking a better design (separating logic from presentation, using an existing template engine) would be better than what PHP offers.
• Good apps. As much as I hate the poorly-written PHP apps, I'm starting to work on Drupal... In this way, apps are a bit like game consoles, you get the one that plays the games you want. I think PHP attracting newbies probably leads to more decent web apps being written in PHP than in o

Pot, kettle, black?

"You don't know that you have to filter user input," Lerdorf exclaimed.

Apparently the much belowed MySQL doesn't know it either, since in contrast to most standard SQL relational databases like Postgresql, it silently trims certain input/fields instead of reporting an error.

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.

I want to move from MySQL

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.

MySQL's problem

the eternal problem with MySQL

I think the eternal problem with MySQL is that everyone thinks that just because "SQL" is in the name it's a relational database. It's not. Sure, it's got tables and you can join tables together and use SQL queries, but it wasn't originally designed to do the things that a relational database must do. It was designed to be a quick, easy-to-use database that made developer's lives easier. And from that standpoint, it does well.

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

PostgreSQL "Slammed" you say?

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.

Who cares? use ORM.

I got sick of the syntax dialects of every SQL engine, so I started writing my applications using Hibernate [hibernate.org] and haven't looked back.

I learned HQL (Hibernate Query Language) and just use whatever database is handy at the time.

I usually start with MySQL 5, and then if I need more muscle (Read: the boss wants to spend money), I can switch the entire application to Oracle in about two hours.

You want ACID...? Use J2EE transactions and Hibernate, and never worry about which database you use again.

Re:Who cares? use ORM.

Who are these people who change databases all the time? We just figured that PostgreSQL was the best, it's free, we know how to use it and tune it, and so that's all we ever use. Now we can use all the wonderful SQL features of PostgreSQL and not worry.

A solution which forced us to regress to using Java or .Net is no solution at all BTW.

Rich.

Pot and Kettle

"'The Web is broken and it's all your fault' says Rasmus Lerdorf, the creator of PHP."

Translation:

"Hello, Kettle? Yes, this is Pot. What colour are you..?"

Really, if Lerdorf wants to know who broke the web, he just needs to look in a mirror.

"a universal fix all"

I got the impression he thinks PHP is a univeral fix all.

There are no universal fixalls except time, effort, and if you are lucky, good documentation.

Use what works, Sometimes PHP is good, other times it sucks. It all depends on your needs and wants. But to inxrease performance over 50x by switching from Postgress to MySQL? I like/use MySQL as my primary DB, but somehow I doubt Postgress is THAT much slower.

I think someone needs to go sit in a corner.

PHP Creator says PHP is great at PHP Conference

Er, this is news?

- Roach

It's entirely a matter of appropriateness

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 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 ...I want PHP and MySQL!

(end of long meandering rant)

The real story here...

PHP 6, which is still in development, will have opcode cache built in by default.

For current PHP 5 users, there are various opcode cache implementations that can be used, including the Alternative PHP Cache (APC), which is what Lerdorf recommended.

APC is broken in so many ways it is unbelievable.

eAccelerator however performs a thousand times better and actually works.

Ever new major php build makes noticeable efforts to break eAccelerator while making concessions to APC.

It is very frustrating. APC just plain sucks. eAcclerator rocks.

Where's the slam?

One performance enhancement that Lerdorf suggested based on code analysis was to use MySQL instead of PostgreSQL for the database. "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.

There's your "slam". Hardly a revelation, really. MySQL & PostgreSQL are two excellent databases that have different target audiences that overlap somewhat. I guess there are different kinds of extremists out there as well...

Postgres

OK here's something I never did understand about postgres:

If you modify a record in a postgres DB it keeps an invisible copy of the original for 'transactional reasons' and does not ever automatically delete it, even if there are no current transactional queries running. This means you can have a DB containing a single one field record and if you keep altering the field value you'll eventually run out of disk space. With any Postgres DB you therefore have to manually run a purge every now and again, and the purge slows the whole DB down to a crawl while its running (for us a purge had to be run every day otherwise the DB performance would be crazy slow, and the purge took over half an hour which during that time hardly any queries would run).

Basically, it just seems like Postgres has shot itself in the foot there.

I spoke to the developers and was told in a rather snooty reply that they had no plans to allow the user to optionally disable transactional 'features'.

Need a 'series' column

I make a living doing LAMP (that's MySQL/PHP) development. I haven't had any data problems with MySQL using version 4.1 to 5.0. Admitedly, I'm not doing fortune 500 work, but I making decent use of the relational features. I looked at Postgres around 2002, but couldn't get past the install and creation of users. I haven't run into a webhost that supports it yet. Basically I have no incentive to really dig into it yet. However, I have found a feature that I would like to see in MySQL.

I have some tables that need to be arbitratily sort by the user. The sorting isn't universal throughout the table, but rather within a foreign key value. So it would look like this:

cat_id | sort_order
1 1
1 2
1 3
2 1
2 2
2 3

It's a big PITA to keep this column properly serialized with the PHP when you want to insert a new value in the middle, or move the values around. I have a restriction to prevent duplicate sort_order keys within the cat_id. I found a serial column type in Postgres. I haven't used it, but it might automagically do that crap I have to take care of in the code.

Summary ignores best PostgreSQL mailinglist reply!

That summary was dreadful, even by Slashdot standards. It completely ignored the reply in which this video demonstrates PostgreSQL performance [youtube.com] relative to MySQL.

Stroller.

and php is not broken?

This guy has some b*lls, I have had the displeasure of using php for a couple of years.

Here [bitstorm.org] is a good summary of some of my complaints. But wait, there is more:

As a programming language, php is extremelly poor. Off the top of my head:

1. Very poor object oriented language. Not everything is an object, no multiple inheritance, use destructors and you get segfaults, etc... They improved a lot with v5 but still.
2. No higher order functions. As opposed to Python, Perl, Ruby, and hundred others.
3. No closures
4. No operator overloading
5. No aspect oriented constructs, metaclasses, decorators, nada

and then there is the issue of all the weird behaviours it has

1. consider this code:

   $x = NULL;
   $x->a = 10;

   What do you expect to happen? well, an exception obviously. NOT, php guesses you really meant to create an object, assign it to $x and that the object has an attribute a. It does not even issue a warning in the logs. Makes it really fun to debug some programs.
2. References are just weird. And they are so different from version 4.0 to version 5.0 that it made it imposible to upgrade for an existing project
3. arrays are passed by value, but objects are passed by reference, WTF?
4. variables are case sensitive, but methods are not. WTF?

The language itself seems to promote what Rasmus calls "broken" code. Magic quotes are just an open invitation for SQL Injection, and XSS vulnerabilities.

For fck sake, the php tutorial [php.net] teaches how to write cross site script vulnerable code which is what Rasmus is complaining about. WTF?????

P.S. Forgive my grammar, english is my second language

Huh?

"just like you can get better performance from a wheel-less Yugo if you slide it down a luge track."

I am sick and tired of seeing these sweeping, baseless statements on Slashdot. The body of a Yugo is much too wide to sit flat on the ice of a luge track.

Editors, please start doing some fact checking before posting this stuff.

mysql not faster

mysql is *not faster than postgresql, even with myisam tables. postgresql has a much smarter query analyzer and on a query to query level is on par with mysql *if* you prepare the statement first. this wasn't true in the 7.x days, but it is true today.

Poor Rasmus

You certainly are taking some heat here, sir.

Regardless, thanks for inventing PHP. 3

ACID

Sorry to break it to that PostgreSQL fan, but MySQL has had ACID transactions for years now, and it's still faster than PostgreSQL for average web app queries. Time to stop making excuses based on half-truths about ancient versions of MySQL and just acknowledge that MySQL is fast.

This is not just a two way debate

First off it s surprizing how many people, even trainned software engineers don't understand SQL databases. I'd bet that most people writting software today don't know what "normal form" means As I see it a dfesigner has three options not two. Yes you can go faster if you use a stripped down database that lacks important features be coding those features into your aplication. But you can go even faster by not using a data base at all and writing directly to the file system. For simple applications where you only have a few thousand items to track and ONLY your one applacation needs to access that data a file works fine. But when you have many, many tables and each is large and the tables are mostly related to each other and (this is the key) you have many applacations written by diferent organizations that all need to access the data at the same time then yu have no bussines to be using MySQL. Most people however write small, simple software. certainly if you are using PHP you are just backing up a web site. I wonder what his vews on Oracle are?

Mod Post -1 Troll

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?

What is this Fox News?

This is among the most mornic slashdot stories I've ever heard. TFA is a little inflammatory, and Mr. Lerdorf is clearly giving a half tongue in cheek conference talk, but why is the story headed 'PostgreSQL Slammed by PHP'? From the article:

One performance enhancement that Lerdorf suggested based on code analysis was to use MySQL instead of PostgreSQL for the database. "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."

If MySQL help's speed up the code, how is that a 'slam' (My translation: insult)? Is the 'unimpressed' PostgreSQL responding to the performance difference allegation? Or is the "MySQL is not a real database" discussion the way they are headed? Wow this is bad.

Fundimental lack of understanding of databases

With all due respect, Rasmus needs schooling when it comes to databases, and a few other things for that matter. If he is interested in a serious debate/discussion, I have his email address and he should let me know, I'll contact him. It's only ignorance if you "ignore" what you don't know.

The problem with MySQL is exactly what he said, that if MySQL doesn't do it, you can do it in PHP. Well, that is just flat out stupid. Dumb. Moronic. A database's job is to deal with data. How many times have I done something easy on PostgreSQL, that MySQL would require a query, PHP work, second query, PHP work, third query, I can't count.

PostgreSQL is not perfect, and it does have its issues, but it has been my experience that, when used correctly, it out performs the likes of MySQL. Yea, sure, when there is little web traffic, MySQL will do better than PostgreSQL with simple queries, but when you have any traffic and/or any non-simplistic queries, PostgreSQL moves in front quickly.

ACID?

Analysis Console for Intrusion Detection? Does it run faster on postres?

MySQL doesn't scale

I recently did a little consulting project for a company with a MySQL database. I was left unimpressed.

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

update datatable a set a.denormed = (select max( b.foo ) from datatable b where a.customer_id = b.customer_id)

A simple correlated subquery self-join in a update. Low and behold, MySQL doesn't allow this,. at all:

"Currently, you cannot update a table and select from the same table in a subquery." (MySQL official documentation, 13.2.10)

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.

Stupid idiot searching for a flame war

I don't think he really SLAMMED PostgreSQL. This guy is just like the media. He is looking for controversy. A lot of what he said is true to a point and he didn't say "Don't use PostgreSQL". He said that general purpose MySQL is in fact faster than PostgreSQL and I be damned. For the most part IT IS!

Look at this response: Turn fsync off and try again. Don't expect your data to stay consistant
tho. Yep, then their is a big BUT. MySQL is fast. If you don't need PostgreSQL, but need the fastest possible speed. MySQL is a good choice. If you can emulate a feature with PHP and it be much faster than using PostgreSQL over MySQL. BINGO! You don't HAVE to use PostgreSQL, but you DO NEED to use the best tool for the job.

Slammed? I think not.

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.

PostgreSQL is faster than MySQL

In my tests PostgreSQL is consistently faster than MySQL and scales much better for multiple CPUs (which matters a lot!!!). Also see this indipendant article: http://tweakers.net/reviews/646/10 [tweakers.net] - you will notice that not only PostgreSQL is faster than MySQL to begin with, but it gets even faster with HypterThreading and so on.

In my professional opinion there are absolutely no reasons to ever choose MySQL over PostgreSQL. The latter is completely free (as opposed to dual licensed), much more powerful, more standard compliant, faster, and better documented.

HaHa!

This always makes me giggle.

This holds especially true on Slashdot, but still applies to other discussion groups... whenever someone mentions Technology X, and talks about it in other then glowing praise, it's always considered to be an attack on said Technology. There is only one exception to this rule, and that is when it comes to anything Microsoft, in which it automatically sucks. Hooray beer^H^H^H^H GroupThink!

Favourite Comment

My favourite comment is this one [postgresql.org]:

PHP makes "wrong things" easy, and "right things" hard.

Evidence: "addslashes", "register_globals" and "magic quotes".

More evidence: PHP Nuke, phpBB, PDO vs PEAR DB.

Taking his advice on software is like taking a coprophagist's advice on fine dining.

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.

Can this guy

Kill off php please and shut up. PHP has the history of being one of the lousiest worst designed languages ever, with slowly catching up to modern standards. I have to deal with that absymality of a language every day, and curse it every day....

It seems strange.

Why would you recommend coding to a specific database and not code to SQL and not worry what you have on the back end?

Binding yourself to a particular technology to get more speed is just wrong. Write code that is generic to the back end and get your speed inside your code, not the database choice.

The database should optimized by the DBA by adding views/indexes/optimized SQL or more hardware to get the speed.

This article would be a whole heck of a lot better

...if it actually said something. It tells of what he talked about. What we really need is a much better article, or a transcript of the actual speech, considering that it sounds like he had many useful and interesting things to say, but they aren't being said to anyone unless you got to go to the conference.

Slashdot

Doesn't Slashdot use MySQL still??
http://www.mysql.com/news-and-events/success-stori es/slashdot.html/ [mysql.com] and http://slashdot.org/faq/tech.shtml#te050/ [slashdot.org] look for (MYSQL).

If it is good enough for SlashDot then it is good enough for me.

Zend's ZActiveRecord Boondoggle

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 [wikipedia.org], 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 [php.net] 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 [php.net] sloppy [php.net] implementation [php.net] caused [php.net] many [php.net] bugs [php.net] that [php.net] CORE [php.net] DUMP [php.net] PHP [php.net]! 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

speed up your database layer

Switch out your Postgresql database for a Mysql database running on speedy ISAM tables.

VROOOOOOOOOMMMMMMMMMMMMMMM!

Is that the sound of your database speeding up, or your data integrity disappearing?

Only Rasmus Lerdorf really knows...

Huh

So he wants me to make up for all the features missing from MySQL by using PHP?

I think I just threw up in my mouth a little.

(helpful hint for mods: this might be considered flaimbait)

There's a surprise

PHP is one of the most poorly-designed languages ever created, and there's no evidence that its designers have really improved much (even some of PHP5's improved features have stupid defaults, for example). It doesn't surprise me that they wouldn't know a good design if they saw one.

Sure, Rasmus

Lerdorf noted that some features can be emulated in PHP itself

Great! I'm very happy now. I'll code 3x more to emulate some things that a REAL RDBMS should do by itself...

Rasmus should try a comediant career, since he lost any ability to make plausible arguments.

An elegant alternative.

For a simple, fast and powerful alternative web technology that leverages PostgreSQL's innate technological superiority, please have a look at http://asmith.id.au/mod_libpq.html [asmith.id.au] Put simply, this apache module allows you to bypass all the middleware baggage and build your web applications directly in your PostgreSQL database yielding tremendous advantages in speed and robustness. One well known example of this technology in action is http://freedb2.org/ [freedb2.org]

because mysql is the paragon of speed?

I'll stick to BDB and C - not noveaux crap like PHP, thanks.

Re:WTF?

I completely agree... WTF

Re:He did *NOT* slam PostgreSQL

Exactly. But it makes a much more interesting /. story to take an imcomplete account of a talk and further mangle it.

I hate to do it but - MOD PARENT UP

...please, in fact, I'd like to know why it was modded down

Re:database usually more robust than apps that use

Play around with ACID, and you're liable to take a header out the window !!

Dude, that's another kind of ACID [wikipedia.org]. It's database ACID [wikipedia.org] (Atomicity, Consistency, Isolation, and Durability), not the stuff that people got high on [wikipedia.org] in the sixties. Concerning the latter, there actually have been unsubstantiated rumors about people who imagined they could fly and took a dive through the window.