Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!


Forgot your password?

PostgreSQL Slammed by PHP Creator 527

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.'"
This discussion has been archived. No new comments can be posted.

PostgreSQL Slammed by PHP Creator

Comments Filter:
  • by Anonymous Coward on Friday September 15, 2006 @11:04AM (#16113612)
    It's very fast and I haven't been killed yet.
    • "PostgreSQL sucks." - From the guy who brought us magic quotes
    • by Rob T Firefly ( 844560 ) on Friday September 15, 2006 @12:01PM (#16114174) Homepage Journal
      The luge isn't something you just dump Yugos on, it's a series of tubes!
  • by DreddUK ( 255582 ) on Friday September 15, 2006 @11:04AM (#16113615) Homepage
    <Sarcasm>Honestly, just avoid this discussion by using flat files.</Sarcasm>
    • That's just nonsense! Oh, sorry, didn't see the Sarcasm tags.
    • by spun ( 1352 ) <loverevolutionar ... m ['oo.' in gap]> on Friday September 15, 2006 @11:11AM (#16113689) Journal
      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!
    • by LWATCDR ( 28044 )
      Actually that isn't as dumb as you might think.
      MySQL is often used some would say abused for things that a flat file would be just fine for.
      Last time I did look MySQL and Postgres where very close in speed. I use Postgres for a lot of in house work but I use MySql for a lot of web work. Most of the CMS packages I see out there have better support for MySQL then Postgres. The program I use I wrote for in house use does a lot of transactions which MySQL didn't support at the time.
      Postgres is a better database
      • Re: (Score:3, Interesting)

        by Anonymous Coward
        PostgreSQL actually did used to be slower in most basic operations than MySQL. This was largely because MySQL used to lack some of the most basic things that make a DBMS relational (for example, for quite a long time there was no ACID compliance at all) whereas Postgres had them right from the start, but they weren't terribly efficient. As MySQL started trying to patch itself up into something a competent DBA wouldn't burst into flames over, PostgreSQL patched itself up to improve performance. The result wa
        • by DragonWriter ( 970822 ) on Friday September 15, 2006 @11:58AM (#16114146)
          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.

    • SQL sucks (Score:3, Insightful)

      by Sloppy ( 14984 )

      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.

    • by jalefkowit ( 101585 ) <`jason' `at' `jasonlefkowitz.com'> on Friday September 15, 2006 @02:11PM (#16115254) Homepage

      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... (Score:5, Insightful)

    by Richard_at_work ( 517087 ) <richardprice@gm a i l . com> on Friday September 15, 2006 @11:05AM (#16113631)
    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... (Score:4, Insightful)

      by linuxwrangler ( 582055 ) on Friday September 15, 2006 @12:24PM (#16114378)
      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.
  • by xmas2003 ( 739875 ) * on Friday September 15, 2006 @11:06AM (#16113635) Homepage
    "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 ...
  • by Mongoose Disciple ( 722373 ) on Friday September 15, 2006 @11:08AM (#16113657)
    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.
  • wow (Score:4, Interesting)

    by aleksiel ( 678251 ) on Friday September 15, 2006 @11:08AM (#16113659)
    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.
    • by billstewart ( 78916 ) on Friday September 15, 2006 @01:19PM (#16114834) Journal
      "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.

  • by grammar fascist ( 239789 ) on Friday September 15, 2006 @11:08AM (#16113664) Homepage
    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.
    • Re: (Score:2, Interesting)

      I'm sure you'll be modded to hell (who knows, maybe me too), but I agree with you entirely.

      Take design advice from the people who brought us "magic quotes" and a configurability that makes it such a pain in the ass to write websites that will work the same on different servers? No thanks!
  • by Gr8Apes ( 679165 ) on Friday September 15, 2006 @11:10AM (#16113678)
    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 (Score:5, Insightful)

    by Chacham ( 981 ) * on Friday September 15, 2006 @11:11AM (#16113683) Homepage Journal

    "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: (Score:3, Interesting)

      by masklinn ( 823351 )

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

      And 3000 redundant functions, and absence of namespaces, and stupid syntax (does ANYONE know why PHP uses $prefixed names? I mean they make sense in Perl or Ruby because they have a meaning, but in PHP?), and the completely stupid misfeatures (register_globals or magic_quotes) which generate as many security holes (flash news: the web is mostly broken because of PHP), and retarded implementations of new features

      • Re: (Score:3, Insightful)

        by nuzak ( 959558 )
        > does ANYONE know why PHP uses $prefixed names?

        Consistency I suppose, since you need the $ to interpolate in a string (which PHP doesn't even manage to do inside HTML without special escape brackets, where velocity and TT2 actually does). You can also call functions through variables that name them, e.g. $foo() so you need the $ to dereference it. You may as well use $ for dereference in all contexts at that point.

        Not that I think that much logic actually went into it. Heck, does it still deep-compar
    • Re:Moo (Score:5, Insightful)

      by 14CharUsername ( 972311 ) on Friday September 15, 2006 @12:41PM (#16114525)

      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.

  • by Rasmus ( 740 ) on Friday September 15, 2006 @11:15AM (#16113716) Homepage
    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.
    • by Azarael ( 896715 )
      Unfortunately this is /. and not one has the interest and/or time to look behind every inflammatory article. All I have to say is that the company that I work for has been using PHP and PostgreSQL in unison and I haven't seen anything that makes me doubt the fitness of that combination.
      • by Rasmus ( 740 ) on Friday September 15, 2006 @11:27AM (#16113833) Homepage
        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.
        • by Savage-Rabbit ( 308260 ) on Friday September 15, 2006 @12:13PM (#16114282)
          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.
          • by Rasmus ( 740 ) on Friday September 15, 2006 @12:23PM (#16114363) Homepage
            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: (Score:3, Insightful)

              by slamb ( 119285 ) *

              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.

              Sure thing. Did you say this?

              Part of the reason Lerdorf considers the Web "broken" is that it is inherently insecure for a variety of reasons. One of those reasons sits at the feet of developers. "You don't know that you have to filter user input," Lerdorf exclaimed.

              If you don't like insecurity due to poor input handling, why did you design your language to encour

    • It seems the Slashdot editors and contributors get their kicks by watching the comment count shoot through the roof. The only way to do that is to misconstrue the truth to get people infuriated about nothing. Unfortunately articles like these distract from those that warrant relevent discussions.
    • Re: (Score:3, Insightful)

      by drinkypoo ( 153816 )
      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?
    • by slamb ( 119285 ) * on Friday September 15, 2006 @01:06PM (#16114716) Homepage
      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.

      • by Rasmus ( 740 ) on Friday September 15, 2006 @01:24PM (#16114879) Homepage
        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.
    • by SanityInAnarchy ( 655584 ) <ninja@slaphack.com> on Friday September 15, 2006 @09:30PM (#16118275) Journal

      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
  • by A beautiful mind ( 821714 ) on Friday September 15, 2006 @11:15AM (#16113723)
    "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.
  • by Anonymous Coward on Friday September 15, 2006 @11:16AM (#16113729)

    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 (Score:4, Insightful)

      by Doctor Memory ( 6336 ) on Friday September 15, 2006 @11:49AM (#16114057)
      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).
  • by tjw ( 27390 ) on Friday September 15, 2006 @11:18AM (#16113744) Homepage
    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.

    • Are you saying a Slashdot editor didn't bother to fully read the article and just made up a sensational and misleading headline in order to troll for mouse-clicks?

      I don't believe you.
  • Who cares? use ORM. (Score:5, Informative)

    by profet ( 263203 ) on Friday September 15, 2006 @11:19AM (#16113749)
    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: (Score:3, Insightful)

      by Deinesh ( 770292 )

      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.
    • by Richard W.M. Jones ( 591125 ) <rich.annexia@org> on Friday September 15, 2006 @02:13PM (#16115287) Homepage
      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.


  • by markbthomas ( 123470 ) on Friday September 15, 2006 @11:20AM (#16113765)
    "'The Web is broken and it's all your fault' says Rasmus Lerdorf, the creator of PHP."


    "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.
  • by kahei ( 466208 ) on Friday September 15, 2006 @11:25AM (#16113813) Homepage
    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:

    tar -xvf
    vim vim vim
    exit ...I want PHP and MySQL!

    (end of long meandering rant)

  • by Anonymous Coward on Friday September 15, 2006 @11:26AM (#16113829)
    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? (Score:3, Interesting)

    by Abu Hurayrah ( 953237 ) on Friday September 15, 2006 @11:31AM (#16113876) Homepage
    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...
  • Huh? (Score:5, Funny)

    by 93 Escort Wagon ( 326346 ) on Friday September 15, 2006 @11:52AM (#16114084)
    "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.
  • Mod Post -1 Troll (Score:4, Insightful)

    by RaisinBread ( 315323 ) on Friday September 15, 2006 @12:13PM (#16114275) Homepage
    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?
  • by orthogonal ( 588627 ) on Friday September 15, 2006 @12:47PM (#16114571) Journal
    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.
  • Favourite Comment (Score:3, Insightful)

    by Bob Uhl ( 30977 ) <eadmund42@nOSpam.gmail.com> on Friday September 15, 2006 @01:21PM (#16114858) Homepage
    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.

  • by SimHacker ( 180785 ) * on Friday September 15, 2006 @02:11PM (#16115256) Homepage Journal

    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

  • by brennz ( 715237 ) on Friday September 15, 2006 @02:14PM (#16115299)
    Switch out your Postgresql database for a Mysql database running on speedy ISAM tables.


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

    Only Rasmus Lerdorf really knows...

Evolution is a million line computer program falling into place by accident.