You mean a Microsoft installer file named something like postgresql-8.0.msi? A single, redistributable file like that?
Looks like there's a file just like that in the Win32 zip download for PostgreSQL. Just bundle up the appropriate install file with your app and you're set.
Available via FTP and bittorrent for your convenience. Admittedly, it wouldn't have helped you two years ago, but it's been there for at least the last six months or so.
Have they sustained break-even point with this technology yet? Have they produced a surplus -- actually generate electricity -- with this technology yet?
According to Henry Hutchinson of the Rutherford Appleton Laboratory in the UK, who set up the European panel, fast ignition requires less laser energy than the conventional approach, which means that it is considerably cheaper.
"The energy problem is sufficiently urgent that we cannot afford to ignore different approaches to fusion," he says.
It's sufficiently urgent that we can't wait for the fusion fairy to visit us. By all means, we should continue research in fusion. It's an exciting field with a lot of potential. But we don't potential so much as a workable energy policy now. We can't base them prototype research facilities that materialize "by the middle of the next decade."
INSERT is very slow (about 3x slower compared to MySQL/InnoDB) for my dataset. The "answer" is to use the COPY command or disable your indexes/FK's which is f*cking lame since you loose all your relational integrity.
That and making sure the insert commands are all done in a single transaction. But I assume you'v done this since you seem to have done your research.
Having to run vacuum all the time to help the query optimizer figure things out. Why this doesn't happen automagically in the background without me having to worry about it is beyond me.
autovacuum
It showed up one day when I did an apt-get dist-upgrade. Works great.
What's the advantage? PostgreSQL for Windows must be downloaded? So does MSDE; it's not shipped with Windows.
And MSDE has that pesky 2GB database limit. That's the hard limit. The fun usually starts around 1.6 gigabytes.
The real advantage of MSDE is that it has exactly the same API that full MS SQL Server has. If you plan on migrating to MS SQL Server, MSDE is a no-brainer. If MS SQL Server is not a clear target--
And Friendster was also slower than tar for a very long time. In addition, when you make changes in Friendster, you may have to wait for those changes to become visible to others. They have some very aggressive caching.
On second thought, who knows? Maybe it used to. That would explain the constant downtime and speed problems.
Proper security is not determining the bad things and preventing them. It's determining what is acceptable and rejecting everything else.
This is true for programs just as it is for programs, including but not limited to database engines. In a sufficiently complex environment, very few people can wrap their heads around every possible combination of variables and logic -- especially when coding with a group. Better to code to what you know is right and reject the rest. It's the only way to be sure.
I guess you've never had a hard deadline coming up and programmed at 4:30am. You're right, the database constraints should not be used as a first line of defense. They do however need to be present as a last line of defense.
Sloppy: Bad data and queries sent to the database
Screwed: Bad data and queries accepted by the database
Most of us try to avoid being sloppy. When that fails (we are human after all), I prefer to not be screwed.
There's more to uptime than the box(es) being up. Netcraft doesn't count when Slashdot has returned 500 status codes because the back-end (read: database) fell over. While it speaks volumes about the reliability of Apache over long periods of time, Netcraft uptimes mean didley in this case for MySQL.
Don't get me wrong. Slashdot's reliability has been steadily improving over the years. Perhaps this is an indication of the stability of MySQL improving over the same interval.
----
Also remember that older articles are archived -- removed from active database queries/updates and rendered to flat text files. Once again, it speaks highly of Apache rather than MySQL.
I loved the CHAR type section, specifically the MySQL entry:
Breaks the standard by silently inserting the string, truncated to specified column CHAR-length.
(It's actually not completely silent, as it issues warnings if values were truncated: If you manually check for warnings, you will know that something bad happened, but not which of the rows are now invalid.)
Debian: apt-get install postgresql (or use Synaptic) Gentoo: emerge postgresql Fedora: rpm -Uvh postgresql-8.0.3.i386.rpm (or select the "Database" package during install) Windows: setup.exe
Easy administration from Windows, OS X, Linux, and BSD with PgAdmin.
Or were you talking about a manual install? Sure that's harder, but most of us don't do manual installs. Just those crazy Slackware folks and their ilk.;-)
MySQL 5.0 is still in development. 4.1 is still the most up-to-date production branch.
You're right that InnoDB has supported row-level locking for some time now. PostgreSQL uses MVCC so that you don't need a lock at all most of the time.
MySQL powers Slashdot
Considering how often Slashdot goes down when they have a cluster of MySQL boxes for redundancy, that's hardly an endorsement of quality.
1. MySQL supports all of the Oracle features you need to build and operate an enterprise software system.
Ummm... no. MySQL does not have user-defined data types, object-relational extensions, full support for the CHECK constraint (a big one IMHO), views in a stable release, updatable views, rules, stored procedures in a stable release, synonyms, support for more than one autoincrement column per table, automatic conversion of code pages between client and server, nested transactions, complete trigger support, access privilege grouping, access to multiple databases in one session, multi-master replication, gateways to other DBMSs, XML data and transformation tools, and better tools for recovery from failures.
You can use MySQL for your enterprise apps, but it is not Oracle. MySQL, while boasting impressive database sizes, is not even close to competing with Oracle (or DB2 or Sybase) on the largest deployed database sizes.
2. MySQL's new administration tools are significantly better than Oracle's out of the box tools (This is why a year ago I refused to use MySQL for production, and now I've switched everything).
The enterprise is not as price-sensitive as the SOHO market. Very few that buy an enterprise Oracle license use the out-of-the-box tools.
3. MySQL is much easier to manage. I don't know anybody who runs a heavily loaded Oracle server in production without spending significant $$$ on DBAs and commercial tools. I feel quite comfortable doing this with MySQL.
See my answer to number 2.
4. MySQL performs pretty much the same as Oracle out of the box (and I think it is easier to tune).
Only in environments that MySQL can handle. Oracle can handle scenarios where MySQL cannot run at all let alone run fast.
5. MySQL's supposed gotchas pale in to comparison to Oracle's. When I first used MySQL BLOBs it simply worked. I opened up the administration programs and I could actually see the images in the database. It was so beautiful I wanted to cry. I can't count the number of times I went through Oracle BLOB/CLOB hell with different platforms. (Not just getting them in there, but actually getting them to work with third party applications which is the real pain.)
Agreed. Oracle definitely has its warts.
That said, migration to and from Oracle is easier with PostgreSQL or Firebird -- especially if you start on the lower end. MySQL has been so far from SQL standard compliance, you may not know when you're doing something really weird. MySQL 5.0's strict mode has helped tremendously with this. Too bad it's not ready for production yet.
PostgreSQL now natively supports BLOBs directly in tables (bytea type) as opposed to using oid references.
PostgreSQL has always had "better than row level" locking, Multi-Version Concurrency Control.
PostgreSQL has added Java and Ruby to its list of stored procedure languages.
----------------
Now, here's the caveat. MySQL 5.0 is still marked as a "development release (use this for previewing and testing new features)" so I didn't include it in the above. If we include MySQL 5.0, we must also include PostgreSQL 8.1, currently in beta.
MySQL 5.0 adds views, stored procedures, triggers, cursors, the bit data type, up to 65K varchar fields, two new storage engines (federated and archive), and a strict mode.
PostgreSQL 8.1 adds two-phase commits, a role system, shared row level locks using SELECT, and many speed improvements.
The strict mode in MySQL is most exciting to me. I always bought the argument that MySQL could have fewer features in exchange for greater speed. But there is no excuse (in my opinon of course) to accept random strings into numeric fields and other such contrivances (MySQL gotchas). Data integrity in a database should not be an optional feature.
Java is one of my languages. So is C, C++, Perl, Python, JavaScript, etc. By the way, the important thing is the algorithms, not the language. VBScript is faster than assembly if the VBS uses a (O)logn and the assembly uses a (O)n^2 on a sufficiently large dataset.
I wasn't just talking about the resource (memory and CPU) scalability; I was talking about the programmer and team scalability. Hmmm... let's see: A loosely-typed scripting language performing tasks for which it was never designed connecting with a database engine that by default silently accepts invalid data. Over time this Big Ball of Mud design pattern, despite the valiant efforts to put checks in the code that your language and database should have done in the first place, will collapse under its own weight as new programmers come into the project.
A single-person or closely-knit programming team? You can probably get by. In the real world where people quit, are rehired months later, new employees of varying ability and habits come on, and late nights with a deadline looming, Big Balls of Mud will start to loose its shape.
I know. I'm a code snob. I actually want my programming languages to be consistent, have a minimum feature set (where are PHP namespaces again?), etc. I want my database engine to -- oh, I don't know -- only accept integer values in an integer field. Think of strict column type checking as a bunch of assert()s in your app. When you do the right thing, it doesn't cost much. When you do the wrong thing, because we all slip at 4:30am, it can show you exactly where the bug is.
That said, PHP 5 and the new MySQL are much, much better than the previous versions. Too bad PHP/MySQL coders keep saying, "Why do I need all that extra stuff?" (Like type checking and code encapsulation.)
"In controversial research reported all over the place, Richard Lynn, the emeritus professor of psychology at Ulster University claims that, on average, men are more intelligent than women. Let battle commence! As the research is not yet published there's nothing more to go on than the press reports. The co-author of the study, Dr Irwing, a senior lecturer in organisational psychology at Manchester University, is apologetic about the findings. In the BBC News report he states that the paper will go on to argue that despite their disadvantage in IQ, there is evidence that women utilise their (lesser!) talents better than men.
This simply begs the question of what use IQ tests are if they don't predict anything in the real world."
Now let's look at my original post.
No, it
raises the question. Begging the question is a logical fallacy involving a circular argument.
While the good doctor may indeed be begging the question with regard to the relative intelligence of women, his article raises the question of what use IQ tests are if they don't predict anything in the real world.
I wasn't making a value judgement. Not only did I want to categorically avoid the discussion on relative IQ between genders, I was simply correcting terminology. You however completely missed the point -- as I earlier stated. Perhaps I should have used quotes -- also stated earlier -- so that it was clear that my statement was illustrating word usage and not stating an opinion. If I had used quotes, someone with your IQ -- presumably above 80 -- probably would have seen my point.
No, it raises the question. Begging the question is a logical fallacy involving a circular argument.
While the good doctor may indeed be begging the question with regard to the relative intelligence of women, his article raises the question of what use IQ tests are if they don't predict anything in the real world.
This extension is EXPERIMENTAL. The behaviour of this extension -- including the names of its functions and anything else documented about this extension -- may change without notice in a future release of PHP. Use this extension at your own risk.
Re: namespaces. How old is PHP? And they're only now getting around to it? Younger languages seem to have them. Why has PHP, a very popular language with an active community, taken so long to implement them if for no other reason than they didn't think it was that important.
Re: design patterns. I see that those have come around since PHP5 was released, now that it has real objects. I also notice that there have been a lot of comments from PHP developers that PHP4 was sufficient, and they saw no need to switch. Wake me when PHP design patterns become relevant, ie. are widely adopted.
As for security... *sigh* From the page you linked:
For real security you should consider providing chrooted jail's for your users.
Good advice, no matter what the product or language. Next quote:
Remember that security risks often don't involve months of prep work or backdoors or whatever else you saw on Swordfish;) In fact one of the bigges newbie mistakes is not removing "<" from user input (especially when using message boards) so in theory a user could secerely mess up a page or even have your server run php scripts which would allow them to wreak havoc on your site.
And here we have a failure of the model. This is yet another classic example why logic should not be embedded in your presentation layer.
best bet is to build php as cgi, run under suexec, with chroot jailed users. Not the best, but fairly unobtrusive, provides several levels of checkpoints, and has only the detriment of being, well, kinda slow. 8)
"Kinda slow" being an understatement. "Kinda slow" guarantees that most PHP users will never use a chroot environment. So we're back to square one.
If your PHP pages include() or require() files that live within the web server document root, for example library files in the same directory as the PHP pages, you must account for the possibility that attackers may call those library files directly.
Any program level code in the library files (ie code not part of function definitions) will be directly executable by the caller outside of the scope of the intended calling sequence. An attacker may be able to leverage this ability to cause unintended effects.
The most robust way to guard against this possibility is to prevent your webserver from calling the library scripts directly, either by moving them out of the document root, or by putting them in a folder configured to refuse web server access. With Apache for example, create a.htaccess file in the library script folder with these directives:
Order Allow,Deny Deny from any
And beginners are equipped to follow -- or even understand -- that last requirement. It's a shame there isn't a policy manager or programmatic sandbox for the code. That would tighten security by default. But wait. I forgot. It will restrict people's programmatic freedom of expression or some such nonsense.
Here is the point that a lot of folks don't seem to get. It is possible to code assembly robustly, securely, and extensibly. However, it is extremely difficult to do so for any non-trivial apps. If more than 75% of PHP coders do not understand what is necessary to secure their environment, I blame the language, not the coders.
Take an example from Java applets -- not the language, the VM in general, or any real or perceived speed problem
Actually, in PHP and PHP/FI days, that was common practice, and in some languages still is.
I meant predecessors like Perl. As for common practice, not in any circles I've been exposed to. Even C tutorials from twenty years ago for command line apps preach distrust and validation of user input as standard procedure.
In the modern internet, the practice is unforgivable.
Except that for years PHP and MySQL, tools marketed to beginners, didn't have the "correct" option available.
And beginners won't know to ask about it. The incorrect option is all they know. The solution, of course, is better tools....and tutorials. There is no excuse as a documentation/tutorial author to demonstrate values injected into SQL strings in examples.
And, once again, there is NO excuse for building a network-aware technology that allows for setting variables from the URI query string. None. Even PHP's predecessors had better sense. It speaks volumes that after it was exposed as the security nightmare that it was, it was simply disabled as opposed to removing it outright. Why? Because it would break existing apps? Guess what? Apps that blindly allow end-user manipulation of variables are already broken.
The correct decision is fixing the flaw, not merely disabling the flaw by default. It should not be an option. If developer need that functionality for some corner-case reason, they should be knowledgeable enough to write the functionality themselves.
That, in a nutshell, is why I don't like PHP. It doesn't present good decision and allow people to make bad decisions, it presents bad decisions by default unless developers write the better behavior themselves -- better decisions that newbies, by definition, will not make.
Slashdot Mirror
But they are initiated by fission reactions. They are not exactly controlled reactions either.
Oh yeah, and it comes with a .NET driver too.
You mean a Microsoft installer file named something like postgresql-8.0.msi? A single, redistributable file like that?
Looks like there's a file just like that in the Win32 zip download for PostgreSQL. Just bundle up the appropriate install file with your app and you're set.
Available via FTP and bittorrent for your convenience. Admittedly, it wouldn't have helped you two years ago, but it's been there for at least the last six months or so.
What was that MSDE advantage again?
Here's my impression of the fusion crowd for the last twenty years.
"We're almost there. We only need minor improvements."
Thank you! You've been a wonderful audience.
Unfortunately technologies like fusion are not just around the corner.
It's sufficiently urgent that we can't wait for the fusion fairy to visit us. By all means, we should continue research in fusion. It's an exciting field with a lot of potential. But we don't potential so much as a workable energy policy now. We can't base them prototype research facilities that materialize "by the middle of the next decade."
My $0.02
autovacuum
It showed up one day when I did an apt-get dist-upgrade. Works great.
What's the advantage? PostgreSQL for Windows must be downloaded? So does MSDE; it's not shipped with Windows.
And MSDE has that pesky 2GB database limit. That's the hard limit. The fun usually starts around 1.6 gigabytes.
The real advantage of MSDE is that it has exactly the same API that full MS SQL Server has. If you plan on migrating to MS SQL Server, MSDE is a no-brainer. If MS SQL Server is not a clear target--
And Friendster was also slower than tar for a very long time. In addition, when you make changes in Friendster, you may have to wait for those changes to become visible to others. They have some very aggressive caching.
On second thought, who knows? Maybe it used to. That would explain the constant downtime and speed problems.
Proper security is not determining the bad things and preventing them. It's determining what is acceptable and rejecting everything else.
This is true for programs just as it is for programs, including but not limited to database engines. In a sufficiently complex environment, very few people can wrap their heads around every possible combination of variables and logic -- especially when coding with a group. Better to code to what you know is right and reject the rest. It's the only way to be sure.
I guess you've never had a hard deadline coming up and programmed at 4:30am. You're right, the database constraints should not be used as a first line of defense. They do however need to be present as a last line of defense.
Sloppy: Bad data and queries sent to the database
Screwed: Bad data and queries accepted by the database
Most of us try to avoid being sloppy. When that fails (we are human after all), I prefer to not be screwed.
There's more to uptime than the box(es) being up. Netcraft doesn't count when Slashdot has returned 500 status codes because the back-end (read: database) fell over. While it speaks volumes about the reliability of Apache over long periods of time, Netcraft uptimes mean didley in this case for MySQL.
Don't get me wrong. Slashdot's reliability has been steadily improving over the years. Perhaps this is an indication of the stability of MySQL improving over the same interval.
----
Also remember that older articles are archived -- removed from active database queries/updates and rendered to flat text files. Once again, it speaks highly of Apache rather than MySQL.
I loved the CHAR type section, specifically the MySQL entry:Beautiful.
Debian: apt-get install postgresql (or use Synaptic)
;-)
Gentoo: emerge postgresql
Fedora: rpm -Uvh postgresql-8.0.3.i386.rpm (or select the "Database" package during install)
Windows: setup.exe
Easy administration from Windows, OS X, Linux, and BSD with PgAdmin.
Or were you talking about a manual install? Sure that's harder, but most of us don't do manual installs. Just those crazy Slackware folks and their ilk.
You're right that InnoDB has supported row-level locking for some time now. PostgreSQL uses MVCC so that you don't need a lock at all most of the time.
Considering how often Slashdot goes down when they have a cluster of MySQL boxes for redundancy, that's hardly an endorsement of quality.
You can use MySQL for your enterprise apps, but it is not Oracle. MySQL, while boasting impressive database sizes, is not even close to competing with Oracle (or DB2 or Sybase) on the largest deployed database sizes.
The enterprise is not as price-sensitive as the SOHO market. Very few that buy an enterprise Oracle license use the out-of-the-box tools.
See my answer to number 2.
Only in environments that MySQL can handle. Oracle can handle scenarios where MySQL cannot run at all let alone run fast.
Agreed. Oracle definitely has its warts.
That said, migration to and from Oracle is easier with PostgreSQL or Firebird -- especially if you start on the lower end. MySQL has been so far from SQL standard compliance, you may not know when you're doing something really weird. MySQL 5.0's strict mode has helped tremendously with this. Too bad it's not ready for production yet.
http://www.huihoo.com/postgresql/mysql-vs-pgsql.ht ml
Changes/corrections since that study was made:
PostgreSQL now natively supports BLOBs directly in tables (bytea type) as opposed to using oid references.
PostgreSQL has always had "better than row level" locking, Multi-Version Concurrency Control.
PostgreSQL has added Java and Ruby to its list of stored procedure languages.
----------------
Now, here's the caveat. MySQL 5.0 is still marked as a "development release (use this for previewing and testing new features)" so I didn't include it in the above. If we include MySQL 5.0, we must also include PostgreSQL 8.1, currently in beta.
MySQL 5.0 adds views, stored procedures, triggers, cursors, the bit data type, up to 65K varchar fields, two new storage engines (federated and archive), and a strict mode.
PostgreSQL 8.1 adds two-phase commits, a role system, shared row level locks using SELECT, and many speed improvements.
The strict mode in MySQL is most exciting to me. I always bought the argument that MySQL could have fewer features in exchange for greater speed. But there is no excuse (in my opinon of course) to accept random strings into numeric fields and other such contrivances (MySQL gotchas). Data integrity in a database should not be an optional feature.
Java is one of my languages. So is C, C++, Perl, Python, JavaScript, etc. By the way, the important thing is the algorithms, not the language. VBScript is faster than assembly if the VBS uses a (O)logn and the assembly uses a (O)n^2 on a sufficiently large dataset.
;-)
I wasn't just talking about the resource (memory and CPU) scalability; I was talking about the programmer and team scalability. Hmmm... let's see: A loosely-typed scripting language performing tasks for which it was never designed connecting with a database engine that by default silently accepts invalid data. Over time this Big Ball of Mud design pattern, despite the valiant efforts to put checks in the code that your language and database should have done in the first place, will collapse under its own weight as new programmers come into the project.
A single-person or closely-knit programming team? You can probably get by. In the real world where people quit, are rehired months later, new employees of varying ability and habits come on, and late nights with a deadline looming, Big Balls of Mud will start to loose its shape.
I know. I'm a code snob. I actually want my programming languages to be consistent, have a minimum feature set (where are PHP namespaces again?), etc. I want my database engine to -- oh, I don't know -- only accept integer values in an integer field. Think of strict column type checking as a bunch of assert()s in your app. When you do the right thing, it doesn't cost much. When you do the wrong thing, because we all slip at 4:30am, it can show you exactly where the bug is.
That said, PHP 5 and the new MySQL are much, much better than the previous versions. Too bad PHP/MySQL coders keep saying, "Why do I need all that extra stuff?" (Like type checking and code encapsulation.)
PostgreSQL is still better.
Now let's look at my original post.
I wasn't making a value judgement. Not only did I want to categorically avoid the discussion on relative IQ between genders, I was simply correcting terminology. You however completely missed the point -- as I earlier stated. Perhaps I should have used quotes -- also stated earlier -- so that it was clear that my statement was illustrating word usage and not stating an opinion. If I had used quotes, someone with your IQ -- presumably above 80 -- probably would have seen my point.
Ad hominem did not come into play.
Keep firing. You seem to have missed the point.
Perhaps I should have used quotes. Then someone with your IQ would have seen it more clearly.
PHP and MySQL not scalable? Say it ain't so!
While the good doctor may indeed be begging the question with regard to the relative intelligence of women, his article raises the question of what use IQ tests are if they don't predict anything in the real world.
From the top of that PDO page you sent me to:
Re: namespaces. How old is PHP? And they're only now getting around to it? Younger languages seem to have them. Why has PHP, a very popular language with an active community, taken so long to implement them if for no other reason than they didn't think it was that important.
Re: design patterns. I see that those have come around since PHP5 was released, now that it has real objects. I also notice that there have been a lot of comments from PHP developers that PHP4 was sufficient, and they saw no need to switch. Wake me when PHP design patterns become relevant, ie. are widely adopted.
As for security... *sigh* From the page you linked:
Good advice, no matter what the product or language. Next quote:
And here we have a failure of the model. This is yet another classic example why logic should not be embedded in your presentation layer.
"Kinda slow" being an understatement. "Kinda slow" guarantees that most PHP users will never use a chroot environment. So we're back to square one.
And beginners are equipped to follow -- or even understand -- that last requirement. It's a shame there isn't a policy manager or programmatic sandbox for the code. That would tighten security by default. But wait. I forgot. It will restrict people's programmatic freedom of expression or some such nonsense.
Here is the point that a lot of folks don't seem to get. It is possible to code assembly robustly, securely, and extensibly. However, it is extremely difficult to do so for any non-trivial apps. If more than 75% of PHP coders do not understand what is necessary to secure their environment, I blame the language, not the coders.
Take an example from Java applets -- not the language, the VM in general, or any real or perceived speed problem
In the modern internet, the practice is unforgivable.
Except that for years PHP and MySQL, tools marketed to beginners, didn't have the "correct" option available.
...and tutorials. There is no excuse as a documentation/tutorial author to demonstrate values injected into SQL strings in examples.
And beginners won't know to ask about it. The incorrect option is all they know. The solution, of course, is better tools.
And, once again, there is NO excuse for building a network-aware technology that allows for setting variables from the URI query string. None. Even PHP's predecessors had better sense. It speaks volumes that after it was exposed as the security nightmare that it was, it was simply disabled as opposed to removing it outright. Why? Because it would break existing apps? Guess what? Apps that blindly allow end-user manipulation of variables are already broken.
The correct decision is fixing the flaw, not merely disabling the flaw by default. It should not be an option. If developer need that functionality for some corner-case reason, they should be knowledgeable enough to write the functionality themselves.
That, in a nutshell, is why I don't like PHP. It doesn't present good decision and allow people to make bad decisions, it presents bad decisions by default unless developers write the better behavior themselves -- better decisions that newbies, by definition, will not make.