Slashdot Mirror
PostgreSQL Slammed by PHP Creator
leifbk writes "'The Web is broken and it's all your fault' says Rasmus Lerdorf, the creator of PHP. He talks about not trusting user input, and the brokenness of IE, which is all fine. Then he makes a statement about MySQL vs PostgreSQL: 'If you can fit your problem into what MySQL can handle it's very fast,' Lerdorf said. 'You can gain quite a bit of performance.' For the items that MySQL doesn't handle as well as PostgreSQL, Lerdorf noted that some features can be emulated in PHP itself, and you still end up with a net performance boost. Naturally, the PostgreSQL community is rather unimpressed. One of the more amusing replies: 'I wasn't able to find anything the article worth discussing. If you give up A, C, I, and D, of course you get better performance- just like you can get better performance from a wheel-less Yugo if you slide it down a luge track.'"
It's very fast and I haven't been killed yet.
Honestly, just avoid this discussion by using flat files.
"If A equals success, then the formua is A=X+Y+Z. X is work. Y is play. Z is keep your mouth shut" - A Einstein.
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.
"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
Hulk SMASH Celiac Disease
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.
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.
Considering that this is coming from the author of one of the worst hack-jobs of a language since Visual Basic, I'm going to have to give his opinions a pass. Pragmatism is great, but even Perl has principles.
I got my Linux laptop at System76.
Why would we listen to the creator of a badly performing broken scripting language about a reliable performance oriented DB?
Not the whole world is interested in rendering HTML tables with blathering text.
The cesspool just got a check and balance.
This guy is an idiot. PHP is a nice product though, if anyone can get past its inconsistent function naming schemes.
He also states:
He *just* learned that? Oh my, that's scary.
MySQL is made for speed compromising to act like a database where it does not break its own convenience. PostgreSQL is a database which will compromise for speed, if it does not break the database.
From someone who obviously is suprised that to secure something you need to make a safe-house and then be strict about what gets in, it seems that he missed the point on the MySQL/PostgreSQL thing.
Maybe by the next conference he'll grow up and state the new revelation "You have to use a database like PostgreSQL and use a warehouse schema to allow faster reporting."
====
Nor was this a "slam". PostgreSQL is not made for specifically web use. If anything, Lerdorf merely publicly demonstrated his own immaturity.
Have you read my journal today?
WTF? Someone guilty of creating PHP complains about the quality of other people's work? This is September 15, not April 1...
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.
"Insightful" heh. You're killing me here.
No folly is more costly than the folly of intolerant idealism. - Winston Churchill
While people might not agree with me that PHP is horribly broken, I think we can all agree that if we were to choose between Apache, PHP and Postgresql as to what made the web more broken, I think almost everyone would pick PHP. The reason can be summed up as bad design decisions in PHP (slashes, inconsistent naming, header fun, etc.).
I don't blast someone if they choose the smaller learning curve with PHP + Mysql, but they're certainly not the superior solution compared to for example Perl/Python + Postgresql/Oracle.
It takes a man to suffer ignorance and smile
Be yourself no matter what they say
I wonder if he has ever consider using Perl ...
I'd prefer to point him towards Python.
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.
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.
GetOuttaMySpace - The Anti-Social Network
The headline implies that Rasmus blames PostgreSQL for breaking the web which is not the case. The focus of his ire is web application programmers for putting too much trust in user input. I don't think anyone can truthfully argue with that.
His comment regarding PostgreSQL was:
"If you can fit your problem into what MySQL can handle it's very fast, you can gain quite a bit of performance."
As someone who uses both MySQL and PostgreSQL in production environments, I couldn't agree more. The key qualifier is "If you can fit your problem into what MySQL can handle". In order to argue that this statement is wrong you would have to argue that PostgreSQL is faster than MySQL in situations that are ideal for MySQL.
XJS*C4JDBQADN1.NSBN3*2IDNEN*GTUBE-STANDARD-ANTI-U
I got sick of the syntax dialects of every SQL engine, so I started writing my applications using Hibernate 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.
Rasmus's first version of PHP (PHP/FI) was written in Perl http://www.kme.eku.edu/tools/php/doc.html#history
"'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.
Not Enterprisey enough. You should be using XML for everything - transactions are just a fad anyway!
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.
34486853790
Connection too slow for X forwarding? Try "ssh -CX user@host"
From wikipedia: 'PHP was originally designed as a small set of Perl scripts'. So yes, he has.
Er, this is news?
- Roach
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.
Recently, I've been using Drupal (PHP CMS system) with a MySQL backend and I am STUNNED, STUNNED I SAY by how productive the combination is compared with, say, ASP.NET and SQL Server. It's a messy, awkward, ambiguous and utterly unscalable language with a cluttered global namespace stuffed full of magic variables and near-identical functions -- combined with a 'database' that simply does not do what a proper database does. And I love it!
...I want PHP and MySQL!
I don't understand this compulsion to prove that PHP and MySQL are good. They're not good. They're sh*t. They're extremely old fashioned and underpowered solutions to problems that are already solved far more effectively in the MS world AND in the OSS world AND even in the proprietary Unix world. Every time I poke around in the Drupal source I have a little smugness session as I think how much clearer and more efficient and more cleanly extendible it could be in C#, or even Java. Then I go right back to using it -- not because it's good, but because for the size of task I'm using it for, it's productive.
Sure, SQL Server is better and so is PostgreSQL, and sure, the antics of LAMP people to prove that PHP and MySQL (and CVS, for that matter) are real grown up systems are laughable. But so what? I'm not trying to be scalable or extensible or secure beyond very narrow parameters that I already know fall within the limited scope of PHP and MySQL. I don't want to use the best tools; I'm familiar with the best tools and the scale of operation they best suit. When I want the following methodology:
GET
gunzip
tar -xvf
vim vim vim
exit
(end of long meandering rant)
Whence? Hence. Whither? Thither.
You still need to store the XML somehow. This is obviously where the flat file format makes sense. Actually, it would be just as funny if someone was actually storing XML in MySql or PostgreSQL. Come to think of it, I bet someone does.
Ben Hocking
Need a professional organizer?
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.
Yes, he did. When he first wrote PHP/FI as a series of Perl scripts back in the middle to late 90s.
Kindness is not to be found in anything but that it adds to its beauty...
It's one of those things that /. geeks can argue in circles about for hours, let them have their fun.
He tried to kill me with a forklift!
Wikipedia isn't the most reliable source. According to the author of PHP, it was meant to replace some Perl scripts.
Kindness is not to be found in anything but that it adds to its beauty...
Databases are usually more robust than the apps that use them. Apps make lots of mistakes, while DBs, even simple ones, usually do a lot better. ACID is fine and dandy, but if it causes my app to be less robust (takes too long, grows files too large, too many files open), then what good is it really? Get in and get out is a good moto. Play around with ACID, and you're liable to take a header out the window !!
.
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'.
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.
Computers are useless. They can only give you answers.
-- Pablo Picasso
This has got to be the most misguided, unrealistic "complaint" about ACID that I've ever seen. I'm sure your warnings attempting to sow doubt in database admins will go completely unheeded.
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.
You're joking right?
PHP is probably one of the crappiest languages alive bar Coldfusion.
"The way we can tell it's C# instead of Haskell is because it's nine lines instead of two." -- wadler
In my day, we had to tatoo our data on our arms with a poison needle, then run our arms through an automated mangler to read it!
I've been writing Perl for 6 years ....
Anyone else misread this as "I've been WAITING for Perl 6 for years"?
"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." And in this regard /. comes to resemble ordinary media outlets more and more. It's sad.
My turnips listen for the soft cry of your love
Stroller.
PHP5 is actually a halfway decent language... the problem is many web hosts don't have it installed yet and there's a huge body of legacy PHP code that doesn't take advantage of it.
But you'd probaby still hate it, since you're one of those Smalltalk bigots. :-)
FWIW, the commercial database UNIFY used to be pretty much the same thing back in the mid-80s. They had a wicked-fast ISAM database, and then they wrapped that all up in an SQL wrapper. They were a little more concientious, though, so you had guaranteed atomic transactions and rollback capability and more complete SQL support (e.g., nested/correlated subqueries), so it was truly relational (as the term is generally used). Horrible syntax-based optimizer, though (actually, I'm not even convinced it was an optimizer, it was probably just the way their SQL parser interpreted the query).
Just junk food for thought...
Here 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:
and then there is the issue of all the weird behaviours it has
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 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
"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.
#DeleteChrome
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.
Not really, it just piles new debatable stuff on top of the old crap. The fact that you can finally have a somewhat useable OO model does not make up for everything else that's wrong in PHP. Especially since the aforementioned model has been ripped straight from Java (statically explicitely strongly typed language) and hacked into PHP (dynamically weakly implicitely typed language).
I actually haven't started studying Smalltalk yet (I'm currently working my way through some Erlang and Haskell right now, along with discovering the Django python framework) ;)
But yeah I still hate PHP5.
"The way we can tell it's C# instead of Haskell is because it's nine lines instead of two." -- wadler
What he actually said was:'If you can fit your problem into what MySQL can handle it's very fast. You can gain quite a bit of performance.'
Everybody who knows anything about MySQL and PostgreSQL knows that. It is completely non-controversial. I would expect the PostgreSQL development team to agree with it.
He implies that in some situations you cannot fit your requirements into what MySQL can handle. Then you need something else, like PostgreSQL.
There's no story here.
"PostgreSQL sucks." - From the guy who brought us magic quotes
/approved
You certainly are taking some heat here, sir.
Regardless, thanks for inventing PHP. 3
Anything can, could, and will happen.
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.
I've been writing Perl for 6 years now and I've yet to find a more versatile language.
I've been writing in Perl for 13 years and detest supporting the crap code written by people who think it's applicable to every problem domain.
SQLite.
Why is it that many people who claim to support standards have such atrocious spelling and grammar?
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?
This article delivers!
And is chuck norris approved
"Good" and "bad" languages are highly subjective, not some kind of universal objective truth. If you like a language that clearly embraces any particular model of programming, PHPs kitchen-sink approach won't have much appeal.
For large projects, I'd think that approach would also make it very hard to maintain compared to languages with a "cleaner" design, but I'm more of a small-project hobbyist, so I don't really know how big of a difference it makes in practice.
I'm personally curious as to why drupal is, in some ways, such a mess.
Because it's in PHP. If all that effort had been in a scalable language promoting encapsulation and well-defined interfaces, Drupal would rule the world. Even so, I think of it as a good mess that's messy according to rules that you can figure out in the end.
All my problems began when I installed the categories module, but now I still have them when it's uninstalled.
The category module has MANY problems and much of what it does you can do with the far more stable and friendly Views module. Unfortunately, Drupal modules typically do nothing when uninstalled -- in other words, nothing is ever really uninstalled, and the DB tables, nodes etc that Category created for you are still present. IMHO the best approach is to maintain a separate Drupal to test modules.
But what's worse is that I posted message about this problem, and then bumped it, and have no replies in two days.
Categories is not a Drupal core module. Feedback on core modules or major modules is often extremely fast and effective, as you can tell by looking at the message histories on the site. However, Categories is more of an 'aspiring Core module' and you shouldn't judge the Drupal community as a whole by the response time on that particular project.
In sum, Categories really represents the 'wild west' of Drupal. Drupal does have some real problems with static tree-like sites, which Categories tries to address, but I wouldn't say that most of Categories is even beta-quality. The real problem is that outside the Core modules, there's no rating of drupal modules -- even though some (Views and CCK to name but two) are extremely powerful almost a necessity.
A secondary problem is that because PHP makes it so hard to define an interface, some modules react badly with each other -- this is especially true of modules that have a Drupal 4.6 way of thinking. Like I said in my first post, I wouldn't think of Drupal as heavy duty scalable expandable software. But once you've learned which parts of town to avoid, I really think it's a very flexible and high-productivity small to medium scall CMS.
Whence? Hence. Whither? Thither.
"Not really, it just piles new debatable stuff on top of the old crap. "
No argument there, but you just can't deprecate everything overnight either.
"Especially since the aforementioned model has been ripped straight from Java"
Yeah, I'd like to see PHP's object model more closely emulate Python's. But take that with a grain of salt: I'm one of those Python bigots. :-)
I think I can be a little more charitable towards PHP, because I started working in IT in an era where it was called DP, and I've seen the COBOL and RPG elephants. *shudder* PHP starts to look really good after you've worked with those eldritch horrors. :-)
Like the creator of PHP is in any position to criticize pg, or anything.
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?
Now that you've gone and made your rational, lucid post...I can't just invoke wit and dismiss PHP (and you in a roundabout way) as so many other quick posters are doing. You do realize you're ruining a perfectly good /. flamewar in the making here, don't you?
/.
Ahh well. C'est la vie...oh, and BTW, it's always a slow day on
""Good" and "bad" languages are highly subjective, not some kind of universal objective truth. If you like a language that clearly embraces any particular model of programming, PHPs kitchen-sink approach won't have much appeal."
You speak the truth. I believe that when we start talking about languages in this context, we should all be reading an implied "in my opinion" in front of it. That's why I poked gentle fun at his sig. This is all in the area of developer/design preferences.
Except for COBOL. That language objectively sucks. ;-)
Thanks for coming by to clear things up. On behalf of at least myself, I'd like to apologize for all the badly-informed sneering in this thread. It's usually bad, but not this bad. And thanks for PHP.
My turnips listen for the soft cry of your love
Great. Now we can have more websites failing because they are built on scripting languages.
Thanks, did that already. I'll stick with jsp or Asp.net..
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.
Oh lord. I do understand much better how you can accept PHP after that indeed.
"The way we can tell it's C# instead of Haskell is because it's nine lines instead of two." -- wadler
Dude, Hollerith cards are for programs. You keep your data on a 9-track tape. That way you know the computer is doing something by the fact that the tape reels are moving back and forth.
This is an old Hollywood convention, and I was very amused to see it revived on Lost. Of course, I have to suspend my disbelief in order to overlook the fact that these tape drives were still working decades after being installed in "the hatch". And also the fact that they were connected to an Apple II!
This coming from the guy who's solution to SQL injection was... Magic Quotes, on by default.
Good job. Lets,
a) Let inexperienced users pretend there is no such thing as SQL injection, or indeed the idea of caring about user input at all, plus pepper lots of PHP generated pages in spurious backslashes.
and,
b) Piss off every experienced developer by making them wrap all their code in Magic Quote detection and associated junk.
I'm sorry, but the person behind the direction of the abominable PHP language and execution environment is *not* qualified to be making judgements about web security or good coding practice.
I hear PHP5 actually has a proper database class now with placeholders, like Perl and every other language has done for *years*?
I bet everyone still uses mysql_*()...
...please, in fact, I'd like to know why it was modded down
PHP through 4.1 was an AWESOME prototyping language... what it was designed for. Back then, you could POST or GET a form, and the variables were automatically filled in. This was a huge security whole, and therefore plugged, which has made it less useful in some ways, but more production friendly in others.
However, my old partner when to a PHP conference, and was STUNNED that the recommended course of action was:
1. Use PHP to prototype
2. Move all business login into C or C++
3. Call the business logic from PHP wrapping the C/C++ calls
While that may be more "correct," that would have massively increased development time.
Our current cycle is like this:
1. Prototype in PHP and PostgreSQL in a test database, treating it like MySQL or Access (a retarded database)
2. Move all validation code into the database with pl/pgSQL, using triggers, etc
3. Performance tune by creating (using triggers) optimized tables for the live site.
4. Deploy
This gets us a lightening fast, reliable system. Unfortunately, for legacy reasons, we have so much PHP code that we've written that migrating to something else (including PHP 5) is hard to justify until we have the budget to get the extra staff just to migrate the system.
It's more work on the DB side, but it's well worth it.
One of the performance tunes we've considered: pl/php, which last time we evaluated it, wasn't quite ready for prime time. Our idea: after tuning your database, move all your database access into the database.
Essentially, for each "page type" on a dynamic site, create a php function that gathers ALL the data you need and puts it into an array. Then, call the Database PHP function getPageType("values to be passed"). The server side PHP function will do all the queries you need, serialize the array, and return it as a TEXT value. Your web page deserializes and displays.
The reason for this is that you have several delays and resource hogs:
1. unoptimized queries: before you move things to stored procedures, test your SQL with explain. Add indexes as needed. If you look up on two or three values, create an index on those values... basic stuff, but will get you massive speed-ups.
2. database connections, to keep this down, put everything on the server into one database and use schemas for access, now you can use persistent connections with a "web" user that connects in persistently and switches as needed (or make your getPage functions accessible to the web user... SECURITY definer, grant execute to the web user).
3. back-and-forth connections: the best way to kill performance, have a PHP script that calls the database, gets some data, calculates on it, and queries again... the fewer queries to the database a page, the better, less overhead. If you need to do back-and-forth activity, write a stored procedure, then there is a single database call. PostgreSQL lets you write stored procedures in SQL, so there is no excuse not to do it.
If you are doing a project of any magnitude, (i.e. 2-3 programmers on it), then one of you should learn to play DBA and optimize the database. If you do that, PostgreSQL is a fast moving beast.
Most performance competitions are MySQL users testing PostgreSQL. However, if you use PostgreSQL like MySQL, it's dog slow. MySQL is a "retarded" database with almost no overhead, so querying the database 15-20 times on a page is harmless. PostgreSQL requires database administration. Once you set up your database right, and tune the server settings (increase buffers, allocate more sort memory, etc.) it screams, but you have to treat it like a real DB.
If you are just throwing your thoughts up on the web, it's not worth it, but if you are doing a real "small" project, where the license for Oracle, DB2, or even MS SQL Server would be extravagant, PostgreSQL is a great option. (The problem with the real databases isn't just the price tag, it's that they are more powerful IF configured right, so you end up needing a 6-figure DBA, instead of a book on database design and about 12 hours to get used to writing triggers).
Alex
I never made the jump to trying PHP because perl already meets all of my needs. Specifically, check out embedded perl. Very powerful stuff: http://perl.apache.org/embperl/pod/doc/Embperl.htm
I've been using html::embperl for about 6 years now, and it works great. It's trivial to modularize (just write your own supporting perl modules). And it takes advantage of mod_perl (pre-load your perl modules as part of the apache process. Good stuff!). Of course, you also have all of CPAN at your disposal this way too.
embperl does some nice escaping and such by default, adding some security benefits.
Excuse me Rasmus, but aren't you teaching how to write XSS vulnerable code in your php tutorial?
One of the problems with the old 7.x series vacuum, is that if you ever end up 1 record over the vacuum memory allocation, then it doesn't properly vacuum it. This means that you are going about your business, vacuum analyze every night, and all of a sudden, your database explodes and fills the hard drive, because old tuples are never cleared out. This is particularly a problem if you have "scrap tables" where the data is constantly deleted, updated, and reinserted... while this isn't reasonable for normalized data, sometiime we have "data cache" tables managed with triggers that store LOTS of data.
If you catch it in time, no problem, but otherwise, you get real problems. Once you get big, you need to vacuum full to avoid this. That's all well and good, but vacuum full can leave the database unavailable while run... this is a problem for a web server database. We can use it on our internal machines no problems (run it Sunday morning, nobody is working then), but it's a problem.
PostgreSQL 8 looks good, but I'm a little scared to migrate ALL the data that we have, and most importantly, screw up any messy optimizations that we've made that made sense on the PostgreSQL 7 engine but not the PostgreSQL 8 engine.
Alex
No argument there, but you just can't deprecate everything overnight either.
Bullshit! I see Microsoft do it all the time...
It's obvious just whose bastard son PHP is .....
PHP takes care to keep things consistent, which is important for easing beginners in gently; Perl is not afraid to eschew consistency where it makes sense to do so. For instance, PHP's regex matching and substitution functions, derived from Perl, are incredibly tedious. In Perl, you're likely to be doing a lot of regex matches: the syntax is such that you just drop 'em in, and let the parser worry about them. No other language I've encountered lets you do that. Even in Python you have to jump through hoops to do what Perl makes simple, and Java seems to go all out to discourage you from bothering with regular expressions.
Some things about Perl are a bit finicky, especially where they involve getting close to the metal. Take for instance the four-argument select function (the one for seeing which file descriptors are ready to present data, expecting data or have just done something they shouldn't, not the one you use for selecting a filehandle for output.) It expects its arguments to be bitmasks created with pack "i", $bits -- you can't just use, say, integers and have them automagically turned into bitmasks. While that sounds a bit un-Perl-like, you have to remember that there are 8999 integers represented by 4-byte strings (and so indistinguible from 32-bit bitmasks). What you really should do is create a wrapper function around select, which takes its parameters (and returns its results) in a more convenient form for the program you are writing.
Je fume. Tu fumes. Nous fûmes!
Analysis Console for Intrusion Detection? Does it run faster on postres?
"Draco dormiens nunquam titillandus."
Hmm... I apologize for using the term "mealy-mouthed" and reassign the label to Leif Kristensen, the submitter of this article (and I'm still probably using the term wrong, oh well).
... eh, who am I kidding, it's typical. Some days I'm kind of sorry I legitimize slashdot by adding anything to it at all.
I still hate the language, but slashdot running this article is
Done with slashdot, done with nerds, getting a life.
Basically, they needed to aggregate data from about 56 million rows in table, and required a self-join as well. I got the consulting contract because this was taking at least six days to complete.
Inputting the 56 million records took about a hour; this included creating three indices.
So far so good. At that point, to make in run faster, I wanted to pre-calculate and deformalize the data the self-join would give. I'd already included columns for this denormalized data in the table, so it was pretty much
A simple correlated subquery self-join in a update. Low and behold, MySQL doesn't allow this,. at all:
Ok, so instead of a subquery we can do a join, but that means we have to throw away the max() operation. Without the max predicate we're doing 1-to-Many joins on b where there is more than one row matching our criteria, and so we're potentially doing multiple updates (all but one of which gets "thrown away") to a row.
Ok, so far so good.
First time around, I included the demoralized column in an index, and of course the update changed the column values. If I dropped and re-created the index, MySQL took about four hours to re-index (four times the time it took to make the index when it BCP'd it in). But if I repaired the index, rather than dropping it, well, it never actually completed, becasue after two days I killed it. What the hell?
Finally, to display the data, I needed to do some date manipulation, a lot of it repeated. In pg, I'd have written the code once, in a user defined function. In MySQL, that requires compiling a shared library, so instead I repeated these rather long calculations in a select. Tedious and error prone. (In MySQL's favor, the built-in date functions are a lot cleaner than T-SQL's.)
Eventually I got a six-day or longer process down to three hours, but it wasn't pretty.
So long story short: a business goes with MySQL because it's "fast". At a certain point, it ceases to scale, and you have to perform "heroic measures", denormalizing and pre-calculating. The index repair is a mess. You can't easily encapsulate code in functions or, prior to 5.0, views. It's no longer fast, and your mission critical business requires calling a consultant to optimize what was perfectly good code before the table size grew.
Opinions on the Twiddler2 hand-held keyboard?
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.
Hell, I detest supporting code *I* wrote even three years ago.
Not because the language is bad, but because the language is so rich that I learn more and better ways to do stuff all the time.
Some times it is really hard not to rewrite something simply because the old way I did it seemed so... uninformed.
And, yeah... every problem I solve is done so with Perl.
Thing is, I don't solve problems that shouldn't be solved with Perl... I pass those off to someone else.
As someone once said: The trick is to use Perl's strengths, not it's weaknessess.
--Phillip
Can you say BIRTH TAX
Hooray for taking shit out of context and blowing it up to pachydermal proportions.
We too have used Emberl 1.3.x for 6 years, and we keep find all sorts of bugs with it. It has a heavy .xs layer, and have had many problems with Seg Faults. We're stuck with it for now because of legacy, but we're planning a move in the near future to Tempate Toolkit,
I'd strongly suggestWhy aren't you encrypting your e-mail?
Nope I have thrown together data structures that I was forced to live with later :(
PERL! code in c like a real man!
Just kidding. Yes programing is been reduced in many cases to looking up the function. PHP is handy for quick projects. I am working with a CMS written in PHP not because I like PHP but because the CMS is so good. I had to drop a really nice CMS that was written in Python from consideration because it didn't use MySQL or Postgres but it's own database. One really nice thing about using MySQL, Postgres, or SQLite is simply the ease of access in a variety of languages. I can write a utility in PHP, Python, Perl, Ruby, or C that can easily pull data out of and push data into a SQL database.
Have a choice of good tools is great. PHP is a good tool. It just isn't a great one.
See my blog http://ilovecookes.blogspot.com/ for light hearted technical information.
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.
Sarcasm or not, I half agree with that.
Today's problem isn't that databases are bad, it's that we use a textual language to interface with databases, and it blurs the line between data and code.
SQL sucks.
As copyright owner of this comment, I authorize everyone to defeat any technological measure which limits access to it.
PHP takes care to keep things consistent
You could have fooled me. PHP has one of the least consistent libraries of any programming language ever created.
GLaDOS for President 2016! "Well here we are again. It's always such a pleasure." -- GLaDOS, 2011
10 years and ditto.
Odds of being killed by lightning and winning the lottery in the same day: 1 in 2^55
Yes he did... and thats why he created another language. *buh dum dum*
:)
I'll be here all week.
This is my sig. There are many like it but this one is mine.
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.
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 - 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.
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.
Bill Stewart
New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks
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!
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.
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....
Oh, man, a _Perl_ programmer talking about the _elegance_ of another language.
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.
Never answer an anonymous letter. - Yogi Berra
...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.
"Champagne for my real friends - and real pain for my sham friends!" http://ericblade.postalboard.com/
The original released version was C. The language itself copied some PERL functionality.
Play around with ACID, and you're liable to take a header out the window !!
Dude, that's another kind of ACID. It's database ACID (Atomicity, Consistency, Isolation, and Durability), not the stuff that people got high on 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.
I used to be a sceptic. These days, I'm not so certain.
Doesn't Slashdot use MySQL still??i es/slashdot.html/ and http://slashdot.org/faq/tech.shtml#te050/ look for (MYSQL).
http://www.mysql.com/news-and-events/success-stor
If it is good enough for SlashDot then it is good enough for me.
Half of writing history is hiding the truth.
The creators of PHP are morons, and their support company Zend is dishonest and incompetent. The ZActiveRecord boondoggle demonstrates exactly what I mean: They can't program their way out of a paper bag, an don't even understand the limitations of the very language that they haphazardly "designed".
It makes me laugh that Lerdorf would slam Postgres, because the PHP designers have no understanding of object oriented programming or databases: instead they invent half baked cargo-cult designs, which are naive reactions to other systems they don't understand: they try to ape their surface features without understanding the reasons behind the way they're designed.
PHP references were thrown in as a band-aid to work around the horrible design flaw that arrays and objects were foolishly DEEP COPIED by default. If you pass or return an array from function to function, its contents are DEEP COPIED, which is EXTREMELY inefficient and leads to all kinds of horrible bugs because it's the last thing a sane programmer would expect. So instead of fixing the design flaw in PHP, they add "references" that LOOK and SOUND like C++ references, but actually are completely different, again misleading programmers into thinking they understand what's going on, but working totally differently than a sane person would expect. PHP references are actually half baked symbol table references. The sloppy implementation caused many bugs that CORE DUMP PHP! PHP references were so poorly thought out and badly designed, that there were many edge conditions that they hadn't considered, that simply didn't work together, caused memory leaks and core dumps, and had useless and confusing semantics: callers passing references, functions declaring that they take references, functions returning references, etc. Compare that to C++'s simple and consistent definition of references in term of pointers. The only way to make a PHP reference to an object is to put it in a variable -- you can't make a reference to a field of an object or the return value of a function without storing it in a temporary variable -- totally unlike C++, and totally stupid.
PHP's object oriented programming system is a half-baked imitation of C++'s object model, haphazardly designed by charlitans who had no clue about the fundamentals of object oriented programming, elegant language design or efficient implementation. First of all, if you're going to try to imitate an existing design without understanding it, then for god's sake, at least imitate a language whose object system doesn't suck, and a language that has similar semantics to the language you're trying to kludge. C++ is a static compiled language, and its object system deeply reflects that fact. (That is to say, there's very little reflection beyond RTTI, because the compiler throws all the interesting stuff away! And C++'s oop design had to make many horrible compromises because the C++ object system was designed to map directly into C semantics [since the original C++ compiler compiled C++ into C.]) Most of those C++ design decisions make absolutely no sense for a dynamic interpreted language like PHP. (Many of them made very little sense for C++ itself, but even less sense in the context off PHP.)
One prime example of how PHP screwed up its object system, is that they blew it on static methods, in a way that makes it impossible to properly implement an ActiveRecord-like ORM (among other us
Take a look and feel free: http://www.PieMenu.com
PHP is backward - Template Toolkit is the way to go.
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...
This is such a false argument.
In many ways, *all* data should be in a database. Any data that is not in a database seeks the functionality of a database. Think about searching for email contacts, or words in a word document. Have you ever realized that a spreadsheet is just a database?
Sure, it is impractical for the world to expect everyone to use a uniform data store, but it would make using, moving, interpreting, searching, etc. data easier.
In a web environment, you would almost NEVER use a flat file. Certainly not without serious locking considerations. In PHP for instance, sessions have to use flock to keep things like frames from causing phantom writes and lost data,
MySQL has no technical merrits over somethig like PostgreSQL or Oracle, while Oracle does cost money, PostgreSQL is also free.
There is already a wrapper function. Its name: IO::Select.
It is part of the CORE since Perl 5.00307.
And maybe you could call this magical function IO::Select, and include it in the perl core distribution.
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)
sic transit gloria mundi
"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.
When all you've got is a hammer all your problems start looking like nails. When you're a DBA you think all data should be stored in a database.
And MS tried to put everything in a database with WinFS. Problem was it too complicated.
So you've never seen a .html file before? What do you think those contain? What about a .php file? .css? .jpg? These are all files that contain data. The contents of all of these files could easily be placed in a database. So why don't we? Because it's much easier to use files for these things. And then there's performance reasons.
And these are the same reasons to use MySQL. Easier to maintain. Better performance.
And simpler design and better performance aren't techincal merits?
Slamb, thanks for asking that question, which was also on my mind. I'd certainly like to know how anyone could have ever conceived of something as dangerous as magic_quotes_gpc and register_globals in the first place, let alone why have they taken so long to remove those flaws?
Those horrible mistakes by PHP's designers are directly responsible for many of the security holes and bugs in millions of PHP programs, because PHP is designed to PRETEND to solve security problems, while failing to actually provide any security. So it's pretty hypocritical to blame the sloppy developers, when you're the one who actually invented those horrible flaws in the first place, and took so long to recognize them as such and remove them.
Thanks a lot for finally removing the foolish flaws that encouraged bad practices, and resulted in many security holes, crashed servers, service interruptions, loss of time, loss of money, and exposure private data, but I'll take a pass on the lecture about the consequences of sloppy programming from the designer of PHP.
-Don
Take a look and feel free: http://www.PieMenu.com
No, seriously, which language did you mean there?
how to invest, a novice's guide
A: So they can warm your hands while you're pushing them.
-Don
Take a look and feel free: http://www.PieMenu.com
They're old, tired, don't serve the purpose well and are really hard to get rid of.
Kind of like a 1960s Pontiac.
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.
http://outcampaign.org/
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.
Er Galvão Abbott - IT Consultant and Developer
You have no idea what you're talking about, do you?
Take a look at the string functions. We have str_replace and strtr. htmlentities and html_entity_decode. Inconsistent underscores. bin2hex and strtolower, they can't decide whether to use 2 or to. Why do some functions begin with "str" and others don't? I'm not using C.
Oh, and I keep getting the arguments mixed up. explode and implode seem backwards. strstr is (haystack, needle); preg_match is (needle, haystack). Why?
May I go on? I can go on.
PHP is the opposite of consistent. Whenever I program PHP, I have to keep a window with the docs open, because I keep having to look up if it's stripslashes or strip_slashes or whatever. Terrible.
Guy asked me for a quarter for a cup of coffee. So I bit him.
Python more-or-less has namespaces. PHP still doesn't.
http://outcampaign.org/
Sissies! Real men still keep their data in boxes... just like we do.**
**Yes, I wish I was kidding.
When all you've got is a hammer all your problems start looking like nails. When you're a DBA you think all data should be stored in a database.
.html file before? What do you think those contain? What about a .php file? .css? .jpg? These are all files that contain data. The contents of all of these files could easily be placed in a database. So why don't we? Because it's much easier to use files for these things. And then there's performance reasons.
I'm not a DBA, I'm a software developer and consultant.
So you've never seen a
Nice strawman, but program files and programatic content are fundimentally different than data.
And these are the same reasons to use MySQL. Easier to maintain. Better performance.
I have seen no evidence that MySQL is easier to maintain, nor is it faster on anything but the simplest queries.
>>>So you've never seen a .html file before? What do you think those contain? What about a .php file? .css? .jpg? These are all files that contain data. The contents of all of these files could easily be placed in a database. So why don't we?
Because your performance goes to shit. Its the same problem Microsoft will hit when they introduce their DBFS or whatever its called.
You mean like when they supported Windows 98 up until July 11, 2006?
no comment
Because this post had nothing to with Microsoft or Duke Nukem.
I don't think the creator of PHP is in any position to be slamming anyone. PHP is a mess and a security nightmare. And MySQL is a toy.
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 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/
You know what's hilarious?
I've been writing in C for 16 years now; other language strengths are Javascript and Bourne Shell variants. I work occasionally with PHP, and it's C-like enough that learning it has been easy. But although some things are just not done elegantly, at least one can say, "okay, this is how you do it in C+UNIX, I'll bet it's the same in PHP". And usually, that leads to a solution within minutes, which is pretty good as far as foreign languages go.
Do daemons dream of electric sleep()?
This of course suffers from the problem that if you decide that you need to change the background colour, you need to modify it in 83-odd .php files.
Nothing about this implies that PHP programmers are forced into such ghastly habits, but I do tend to find habits repeated :-(.
If you're not part of the solution, you're part of the precipitate.
You ignorant idiots have now progressed to attacking php.net, which is now down. Are you proud of yourselves? Get out of the business if this is how you want to act.
There are also folks who've been writing Perl 6 for years now.
If I understood the parent post, the temporary copies of the records are never deleted. That's a coding error to me.
He didn't mean about never using them, rather that at some moment, after the queries have run to completion, and all related transactions have finished the commit, and the temporary records are not needed anymore, then have those records deleted.
And they should be deleted. I surely can't understand your rant.
We are Turing O-Machines. The Oracle is out there.
Nothing to do with computer science???
And then what is supposed computer science about? French fries?
FYI: computer science is about algorithms, and guess what... software is algorithmic in nature!
You can't separate a very specific piece of software from the underlying algorithms it has.
However, (and I guess that's the point you tried to make) I believe I can blame more the underlying algorithms in the MySQL engine than the ones in the webpages that use that particular engine.
We are Turing O-Machines. The Oracle is out there.
The analogy, was just an example of how it worked, not a design spec. I also said "for lack of a better analogy." Often in engineering, one must explain concepts in general terms, and leave the specifics to further study.
PostgreSQL's MVCC is analogus to Java's memory management, but not like it.
There is an amount of work/time required to update a record. One must block writers during this time, or use some sort MVCC. If you have MVCC, there little or no blocking, but you have to clean up. If you don't have MVCC you have to block for writes and scale like crap. The work/time has to be done at some point, PostgreSQL uses MVCC and requires VACUUM to clean up periodically.
...from b0rk3n PHP webscripts than from PostgreSQL installations.
I'm not repeating myself
I'm an X window user; I'm an ex-Windows user
...but there are libraries for that. e.g. ADODB
PHP started as a Perl script written by Rasmus Lerdorf for his personal home page.
> Allowing programmers to name serious 'flagship' Linux applications is right
> in line with letting marketing write them.
I assume you are referring to Free Software applications. Who is going to "not allow", management? Who is going to do the naming instead, marketing?
If you know of some "serious 'flagship' Linux applications" that are, in your opinion, misnamed, why don't you just fork them and give the better names?
Warning: this article may contain humor, sarcasm, parody, and perhaps even irony. Read at your own risk.
Funny thing about that saying; I was watching my mate's dad put together a bookcase once, and he would hammer the screws in about 3/4 of the way and then tighten them conventionally. I thought it was a bit weird, but he seemed to think it was a perfectly adequate method of construction.
BTW: He taught engineering at university.
Me lost me cookie at the disco.
Jason asks on his blog:
About face! Retreat! Whitewash web site!!!
-Don
Take a look and feel free: http://www.PieMenu.com
I was thinking more in terms of their migration from different VB's and such.
Deprecation is a necessary evil. Sometimes, and I'm sure both side of the Micorosft field would agree, it's a lot easier if you can do deprecation overnight.
I agree with that regarding VB...I am still trying to stop usinh strHungarianNamingConventions, and start using camelCase. :)
no comment
Its no fun if you make it sound all reasonable.
*smacks fist into palm*
Quack, quack.
I'll stick to BDB and C - not noveaux crap like PHP, thanks.
If you want to see where Rasmus really stands, ask him how he feels about the idea of PHP ever supporting connection pooling as I did when he came to Portland. He got very anxious, irritated and flush in the face as he spouted off lots or fantasy scenarios that made no sense whatsoever.
I said, all the bigger full featured RDBM's were built on the concept and it is fundamentally accepted as the way to scale out. Again he went off, getting more and more irritated.
Just like the importance of supporting Unicode natively, and dozens of other things in PHP, connection pooling will be a distant after thought that will come a day late and a dollar short. My prediction is PHP10.