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.'"
I love my Yugo luge commute (Score:4, Funny)
Summary of article (Score:3, Funny)
Not a great idea at all. (Score:5, Insightful)
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 (Score:4, Funny)
Re:I love my Yugo luge commute (Score:4, Insightful)
Re:I love my Yugo luge commute (Score:5, Informative)
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.
Re: (Score:3, Informative)
Can we PLEASE stop beating this particular dead horse?
First off, the grandparent implied ACID was worthless. Not me.
When some idiot MySQL fanboy says ACID is worthless, I'm going to make sure anyone new to databases who reads the thread learns the truth.
Secondly, MySQL fanboys keep talking about how great it is at speed, and the only way modern MySQL is significantly faster than modern Postgres is when you use the non A
Re: (Score:3, Interesting)
Avoid databases... (Score:5, Funny)
Re: (Score:2)
Re:Avoid databases... (Score:5, Funny)
Re:Avoid databases... (Score:5, Funny)
Re:Avoid databases... (Score:5, Funny)
Re:Avoid databases... (Score:5, Funny)
Re:Avoid databases... (Score:5, Funny)
Re:Avoid databases... (Score:5, Funny)
Re:Avoid databases... (Score:5, Funny)
Maybe this too far...
Re:Avoid databases... (Score:5, Funny)
...When the system crashed, you knew it crashed. That's how we lost Ug, we really miss Ug.
Re:Avoid databases... (Score:5, Funny)
Re:Avoid databases... (Score:5, Funny)
Re: (Score:3, Funny)
Re:Avoid databases... (Score:5, Funny)
Re:Avoid databases... (Score:4, Funny)
Re: (Score:2)
Re:Avoid databases... (Score:5, Funny)
Re:Avoid databases... (Score:5, Funny)
We only had ones because the zeros were too fat to fit through our tiny wires.
Re:Avoid databases... (Score:4, Funny)
Re: (Score:3, Funny)
huge honking boxes of punchcards
We had punchcards but we didn't have keypunch machines. We had to take X-Acto knives and cut out perfect little tiny rectangles from each card by hand. Putting a simple 100-line program on cards could take over a year. I started my first programming class (Fortran 101) in 1974 and I'm on schedule to finish it next year. My first TA passed away seven years ago from old age.
* * * * *
Do not compute the totality of your poultry population until all the manifestations of
Re: (Score:2)
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)
Re:Avoid databases... (Score:5, Insightful)
Personally, I don't care what it used to be, I care what it is now. And, even if I did, I don't see how either course you describe is worse than the other. They are different development models, and depending on your needs the products will have very different advantages and disadvantages before they converge to both being relatively feature-complete and efficient, but generally neither is worse or better.
If you use it, and it works, and you have people that are more productive maintaining it than some other languages, it is, ipso facto, an "actual useful programming language".
Now, it might lack features that you would find ideal in a perfect world where everyone shared your background and tastes, but that doesn't stop it from being actually useful.
I've reconsidered. I still think you seem to be an insecure language and database elitist with a strong need to feel superior to everyone whose preferences differ from yours, and a deep resentment that your favored tools aren't always the most popular.
Re:Avoid databases... (Score:4, Interesting)
No, I've admitted that, several times, in this thread.
There are many ways to rank the functionality of things, not one correct way.
Which is, in fact, what a lot of web applications on LAMP infrastructure do.
"Superior as an RDBMS" is mostly a meaningless, or at least equivocal and ambiguous, category.
Sure, in the sense that "different" is not "equal".
"Inferior programming language" is meaningless.
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."
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?
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 isn't a matter of complicated. It is a matter of wrong.
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.
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: (Score:3)
Let's take the old adage "good, fast, cheap: pick two", and use that as our basis.
Both PostgreSQL and MySQL chose cheap. PostgreSQL then chose good, while MySQL chose fast.
Which approach is better? It's hard to say, but FAST benefits everyone, while GOOD benefits only the elite.
From a pure business perspective, the choice to be fast was of greater benefit to more users, and hence should have been higher priority.
One word: (Score:5, Insightful)
SQL sucks (Score:3, Insightful)
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.
Re:Avoid databases... (Score:4, Interesting)
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:
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
But this is for a database (Score:2)
Re: (Score:3, Informative)
They do. And unfortunately I have direct experience with these people... and for the record, I *mostly* hate it.
Where I work, some of the architects and designers have decided to store more than a little XML in Oracle tables. In some cases this is not an entirely onerus decision (i.e. can make sense). e.g. if you are storing standardized configuration information in XML that will be queried as a string from the table and can be used by/passed to different consumer services/applications as an atomic unit
So... (Score:5, Insightful)
Re:So... (Score:4, Insightful)
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 ... (Score:5, Funny)
I wonder if he has ever consider using Perl
Re:There ARE other scriping languages besides PHP (Score:2)
Re: (Score:2)
I'd prefer to point him towards Python.
Re:There ARE other scriping languages besides PHP (Score:4, Interesting)
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: (Score:3, Insightful)
I've been writing in Perl for 13 years and detest supporting the crap code written by people who think it's applicable to every problem domain.
Re:There ARE other scriping languages besides PHP (Score:2)
Re:There ARE other scriping languages besides PHP (Score:5, Informative)
Re: (Score:3, Informative)
Let me be the first to say... (Score:5, Insightful)
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... (Score:5, Funny)
wow (Score:4, Interesting)
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 (Score:4, Interesting)
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 (Score:4, Insightful)
Re: (Score:2, Interesting)
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!
Depends what you are doing... (Score:5, Insightful)
However, my old partner when to a PHP conference, and was STUNNED that the recommended course of action was:
1. Use PHP to prototype
2. Move all business login into C or C++
3. Call the business logic from PHP wrapping the C/C++ calls
While that may be more "correct," that would have massively increased development time.
Our current cycle is like this:
1. Prototype in PHP and PostgreSQL in a test database, treating it like MySQL or Access (a retarded database)
2. Move all validation code into the database with pl/pgSQL, using triggers, etc
3. Performance tune by creating (using triggers) optimized tables for the live site.
4. Deploy
This gets us a lightening fast, reliable system. Unfortunately, for legacy reasons, we have so much PHP code that we've written that migrating to something else (including PHP 5) is hard to justify until we have the budget to get the extra staff just to migrate the system.
It's more work on the DB side, but it's well worth it.
One of the performance tunes we've considered: pl/php, which last time we evaluated it, wasn't quite ready for prime time. Our idea: after tuning your database, move all your database access into the database.
Essentially, for each "page type" on a dynamic site, create a php function that gathers ALL the data you need and puts it into an array. Then, call the Database PHP function getPageType("values to be passed"). The server side PHP function will do all the queries you need, serialize the array, and return it as a TEXT value. Your web page deserializes and displays.
The reason for this is that you have several delays and resource hogs:
1. unoptimized queries: before you move things to stored procedures, test your SQL with explain. Add indexes as needed. If you look up on two or three values, create an index on those values... basic stuff, but will get you massive speed-ups.
2. database connections, to keep this down, put everything on the server into one database and use schemas for access, now you can use persistent connections with a "web" user that connects in persistently and switches as needed (or make your getPage functions accessible to the web user... SECURITY definer, grant execute to the web user).
3. back-and-forth connections: the best way to kill performance, have a PHP script that calls the database, gets some data, calculates on it, and queries again... the fewer queries to the database a page, the better, less overhead. If you need to do back-and-forth activity, write a stored procedure, then there is a single database call. PostgreSQL lets you write stored procedures in SQL, so there is no excuse not to do it.
If you are doing a project of any magnitude, (i.e. 2-3 programmers on it), then one of you should learn to play DBA and optimize the database. If you do that, PostgreSQL is a fast moving beast.
Most performance competitions are MySQL users testing PostgreSQL. However, if you use PostgreSQL like MySQL, it's dog slow. MySQL is a "retarded" database with almost no overhead, so querying the database 15-20 times on a page is harmless. PostgreSQL requires database administration. Once you set up your database right, and tune the server settings (increase buffers, allocate more sort memory, etc.) it screams, but you have to treat it like a real DB.
If you are just throwing your thoughts up on the web, it's not worth it, but if you are doing a real "small" project, where the license for Oracle, DB2, or even MS SQL Server would be extravagant, PostgreSQL is a great option. (The problem with the real databases isn't just the price tag, it's that they are more powerful IF configured right, so you end up needing a 6-figure DBA, instead of a book on database design and about 12 hours to get used to writing triggers).
Alex
Re: (Score:3, Insightful)
And We'd listen to the creator of PHP (Score:4, Insightful)
Not the whole world is interested in rendering HTML tables with blathering text.
Moo (Score:5, Insightful)
This guy is an idiot. PHP is a nice product though, if anyone can get past its inconsistent function naming schemes.
He also states:
He *just* learned that? Oh my, that's scary.
MySQL is made for speed compromising to act like a database where it does not break its own convenience. PostgreSQL is a database which will compromise for speed, if it does not break the database.
From someone who obviously is suprised that to secure something you need to make a safe-house and then be strict about what gets in, it seems that he missed the point on the MySQL/PostgreSQL thing.
Maybe by the next conference he'll grow up and state the new revelation "You have to use a database like PostgreSQL and use a warehouse schema to allow faster reporting."
====
Nor was this a "slam". PostgreSQL is not made for specifically web use. If anything, Lerdorf merely publicly demonstrated his own immaturity.
Re: (Score:3, Interesting)
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)
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)
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.
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.
Re: (Score:3, Insightful)
Yeah, for those rare cases where consistency isn't important. That covers almost every web app.
See, consistent data is pretty moot in most web apps. I can store the location of an image and then, oops, someone deletes the image file. What's the result? Well technically the data is still consistent within the database, all my foreign keys check out and everything. But I still end up with a broken web page.
So I have to write some code somewhere to make sure that all the images my database points to are r
Rather incomplete quote (Score:5, Informative)
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: (Score:2)
Re:Rather incomplete quote (Score:5, Insightful)
Re:Rather incomplete quote (Score:4, Insightful)
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 (Score:5, Informative)
Re: (Score:3, Insightful)
Sure thing. Did you say this?
If you don't like insecurity due to poor input handling, why did you design your language to encour
Re:Rather incomplete quote (Score:5, Insightful)
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: (Score:2)
Re: (Score:3, Insightful)
Re: (Score:3, Interesting)
Re:Rather incomplete quote (Score:5, Informative)
Re:Rather incomplete quote (Score:4, Insightful)
It's news to me. I haven't seen a recent benchmark that says this, and I'm always skeptical of claims MySQL is faster:
Seriously, if you can prove MySQL is faster for a real-life situation, write a paper, lay all your steps out for review. (Or point me at one someone else has done on modern versions of said databases.) There are lot of potential mistakes in benchmarking, and I won't believe claims unless I actually see that none of them were made.
By the way, what were you saying about Apache header stupidity? The article is annoyingly vague.
Re:Rather incomplete quote (Score:4, Interesting)
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: (Score:3, Insightful)
Okay...so is that what you were talking about here?
If so, why are you complaining about something that has no significance? If not, what are you talking about?
Re:Rather incomplete quote (Score:4, Interesting)
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:
To be fair, I have found some advantages:
Re:Rather incomplete quote (Score:5, Informative)
Pot, kettle, black? (Score:4, Insightful)
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 (Score:5, Insightful)
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)
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? (Score:5, Insightful)
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.
Say it ain't so (Score:3, Funny)
I don't believe you.
Who cares? use ORM. (Score:5, Informative)
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)
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.
Re:Who cares? use ORM. (Score:4, Interesting)
A solution which forced us to regress to using Java or .Net is no solution at all BTW.
Rich.
Pot and Kettle (Score:3, Funny)
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.
PHP Creator says PHP is great at PHP Conference (Score:2)
- Roach
It's entirely a matter of appropriateness (Score:4, Insightful)
I don't understand this compulsion to prove that PHP and MySQL are good. They're not good. They're sh*t. They're extremely old fashioned and underpowered solutions to problems that are already solved far more effectively in the MS world AND in the OSS world AND even in the proprietary Unix world. Every time I poke around in the Drupal source I have a little smugness session as I think how much clearer and more efficient and more cleanly extendible it could be in C#, or even Java. Then I go right back to using it -- not because it's good, but because for the size of task I'm using it for, it's productive.
Sure, SQL Server is better and so is PostgreSQL, and sure, the antics of LAMP people to prove that PHP and MySQL (and CVS, for that matter) are real grown up systems are laughable. But so what? I'm not trying to be scalable or extensible or secure beyond very narrow parameters that I already know fall within the limited scope of PHP and MySQL. I don't want to use the best tools; I'm familiar with the best tools and the scale of operation they best suit. When I want the following methodology:
GET
gunzip
tar -xvf
vim vim vim
exit
(end of long meandering rant)
The real story here... (Score:3, Informative)
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)
Huh? (Score:5, Funny)
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)
MySQL doesn't scale (Score:5, Insightful)
Basically, they needed to aggregate data from about 56 million rows in table, and required a self-join as well. I got the consulting contract because this was taking at least six days to complete.
Inputting the 56 million records took about a hour; this included creating three indices.
So far so good. At that point, to make in run faster, I wanted to pre-calculate and deformalize the data the self-join would give. I'd already included columns for this denormalized data in the table, so it was pretty much
A simple correlated subquery self-join in a update. Low and behold, MySQL doesn't allow this,. at all:
Ok, so instead of a subquery we can do a join, but that means we have to throw away the max() operation. Without the max predicate we're doing 1-to-Many joins on b where there is more than one row matching our criteria, and so we're potentially doing multiple updates (all but one of which gets "thrown away") to a row.
Ok, so far so good.
First time around, I included the demoralized column in an index, and of course the update changed the column values. If I dropped and re-created the index, MySQL took about four hours to re-index (four times the time it took to make the index when it BCP'd it in). But if I repaired the index, rather than dropping it, well, it never actually completed, becasue after two days I killed it. What the hell?
Finally, to display the data, I needed to do some date manipulation, a lot of it repeated. In pg, I'd have written the code once, in a user defined function. In MySQL, that requires compiling a shared library, so instead I repeated these rather long calculations in a select. Tedious and error prone. (In MySQL's favor, the built-in date functions are a lot cleaner than T-SQL's.)
Eventually I got a six-day or longer process down to three hours, but it wasn't pretty.
So long story short: a business goes with MySQL because it's "fast". At a certain point, it ceases to scale, and you have to perform "heroic measures", denormalizing and pre-calculating. The index repair is a mess. You can't easily encapsulate code in functions or, prior to 5.0, views. It's no longer fast, and your mission critical business requires calling a consultant to optimize what was perfectly good code before the table size grew.
Favourite Comment (Score:3, Insightful)
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.
Zend's ZActiveRecord Boondoggle (Score:5, Insightful)
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 (Score:3, Funny)
VROOOOOOOOOMMMMMMMMMMMMMMM!
Is that the sound of your database speeding up, or your data integrity disappearing?
Only Rasmus Lerdorf really knows...
Re:He did *NOT* slam PostgreSQL (Score:4, Interesting)
Re: (Score:3, Insightful)
Open-source GPL + optional commercial licensing not good enough for you?
real database
But maybe we don't need a "real" database. Maybe we need an easy-to-use replacement for flat files with some database features. Not everyone is running a bank, or handling a billion emails a day, or tracking inventory for Wal-Mart. Lots of users just want something that can handle their small little application.
IMHO, one of the reasons why the web is broken is that it is so easy to c
Re: (Score:3, Informative)
Under MSSQL, there's no way of reading stuff from a table and not having the possibility of blocking something else or getting blocked. It's a trivial mistake to make, open the Enterprise Manager, load a big view or table and leave it open. The darn thing will keep a lock on the table unless you scroll down to the bottom of the result list.
You can use the WITH(NOLOCK) hint, but that's crap, as now you get uncommitted data in your SELECT.