I agree with a great deal of what you're saying, but doing this:
Furthermore, it is still common enough practice in large companies for admins to install something stable (like Linux, a *BSD, or whatever) in place of a Windows server, but not to tell their bosses. So long as nothing goes wrong, everyone's happy - the system will crash less often and handle more users, so CEOs and the like are not going to make any enquiries as to what is being used.
to any production system would be a sackable offence.
The operational architecture people would go ballistic.
Porsches quite heavy cars- but there's a certain thrill from driving a car weighing virtually nothing and lots of power through the rear wheels. Nothing wrong with glass-fibre.
I bought a TVR Chimaera a little while ago- 350bhp and it weighs something like 1060kg. 0-60 in 4.1secs - lots of fun!
Dasher is not hunt-and-peck... I've just downloaded it and it's very clever! I think it would be much easier though with a stylus and not my laptop's finger-pad-thing!
Oh, and I can do 30wpm hunting and pecking quite easily.
One good reason to use DB2 is that neither MySQL nor PostgreSQL can scale to the same size of database as DB2. Using DB2's "Distributed Partitioning Facility", or DPF, with DB2 Enterprise Server Edition you can partition data over hundreds of machines using a shared-nothing approach. This means you can create a data warehouse of a hundred terabytes that 1) appears to your applications as just a single database 2) retrieves query results blazing fast (this is the "shared nothing" part; each machine knows what data it is responsible for, so a query that comes in to the database is automatically distributed to the responsble machines, which go off and do their work, then return the results to a single co-ordinator that pipes them back to the application -- it's like RAID-0 for databases).
I completely agree with the above statement, but if you are using PostgreSQL for big Tb+ databases, the new 8.1 version has some partitioning-like features which will really help.
(I agree with many of the chap's comments about Mammoth skiing- I worked as a ski instructor there once... but Courchevel/les 3 Vallees in France is still so much better!)
Apache-group software is excellent, but can indeed be confusing. There is so much there of merit, which just isn't understood.
I use Apache 2 and don't get too concerned about the accompanying fluff; so long as I can configure it, it doesn't concern me. But woe betide the person who can't and has to go to apache.org and fight to get through the content there to what he actually needs!
I suspect 99.9% of Apache software used is the web server. Perhaps the Apache group has grown too far.
I also have a WL-500g Asus router- it's fantastic. Very reliable, with full Linux and USB.
I have disks and printers/scanners plugged in to mine.
Re:Congratulations to the PostgreSQL Team!
on
PostgreSQL 8.1 Available
·
· Score: 2, Informative
Indeed- congratulations.
I'm using PostgreSQL for many things (custom app, Drupal, Apache logging, back-office) and it's great- this new release adds lots of useful bits.
Probably the most useful new feature for those who use it to run mini web sites will be the MAX() and MIN() functions now using indices- this has been a point of contention for some time.
XA will be useful for bigger stuff.
I'm also really pleased auto-vacuum is now part of the DB.
I just bought a couple of P3 800MHZ boxes, with 8GB disks and 256MB RAM for 40 UK pounds each (inc. postage) for a friend- rather overpowered for what I was going to use them for, but cheap as chips.
And I probably could have found a better deal somewhere else...
1000 pounds would buy you 25 of these: that's 20GHZ of P3 goodness in a cluster. Not that I would advise doing so, but for the price, these old boxes are fab.
Got to agree with you- VIEWS and triggers are great, but stored procedures are a real pain. However, they make triggers SO powerful (check out this blog entry on synchronising Apache passwords by one of the PostgreSQL developers).
I'd really like to know how you are supposed to edit stored procedures without programs like phppgadmin.
The above post is accurate, but don't be confused and think "prepared SQL" is the same thing. Prepared SQL is similarly pre-parsed and pre-planned so you get decent performance benefits. And no chance of SQL injections hacks. (Why do so few people use prepared SQL? It's not complicated!)
Also bear in mind that a stored procedure could be *anything*. Postgres allows you to use perhaps half a dozen common languages; Oracle and DB2 similarly. I have no idea what MySQL allows- probably similar. You could write your whole application in the DB if you really wanted to.
Very few (recent) comparisons around. From my experience, however, if you're running a simple web site with many SELECTs over a single table then MySQL may well suffice. If you're doing serious stuff with multiple table/view joins then you should move up a gear and use PostgreSQL.
I've moved completely to PostgreSQL (works beautifully on core Drupal too) and have found complex queries complete in a fraction of the time. I had a complicated application which had multiple threads inserting, updating and reading all at the same time- complete run-time was reduced to a tenth by using PostgreSQL.
It works for me- just make sure you use ADODB in PHP or Perl/DBI to make switching easy when you hit the MySQL limits.
One more thing: I work with serious mainframe DB2 during the day. MySQL just doesn't compare. Postgres feels closer.
The actual project was to do the ethernet audio stuff- I didn't want to play with DACs at all as they get VERY complicated VERY quickly. The PCM54s were rather nice chips, with a straightforward example use on the datasheet- having to faff around with opamps and resistors would have been fun for about two minutes but I wanted to get on with the challenging stuff:-)
Ah the days of 741 and 555s... when everything was simple...
Nothing special
on
TCP/IP Speakers
·
· Score: 4, Interesting
I built a networked DAC a few years ago at university. Not too hard- the complex bit is making the timing and sync accurate, with the limitations of tiny chip controllers and rather unaccurate ethernet chip documentation!
Due to TCP/IP delays e.g. switching, you need some sort of buffering, which ends up meaning expensive memory on small chips. Once you have buffering e.g. 0.2 seconds, you should be fine. I ended up using a couple of little Burr-Brown PCM54 DACs, but the system was designed to feed digital into a decent professional DAC.
Disneyland Japan has had audio over ethernet for years as well; the setup there is huge, with hundreds of speakers over a large area.
I had a similar problem only this morning. I deleted all the rows from a table (by using DELETE FROM) and SELECT COUNT(*) went from sub-second to two minutes.
That's after going from 400,000 rows to zero.
VACUUM ANALYZE made no difference; however VACUUM FULL sorted it out. You should really have auto vacuum running, but for the dev I am doing I prefer to do it by hand.
From what you're saying, this could be the reason why it takes so long.
For what its worth, I've moved to Postgres because it's just so more solid. It's fantastic software. And I know what I'm talking about- I'm heavily involved in (big) mainframe DB2 at work.
Slashdot Mirror
to any production system would be a sackable offence.
The operational architecture people would go ballistic.
Porsches quite heavy cars- but there's a certain thrill from driving a car weighing virtually nothing and lots of power through the rear wheels. Nothing wrong with glass-fibre.
I bought a TVR Chimaera a little while ago- 350bhp and it weighs something like 1060kg. 0-60 in 4.1secs - lots of fun!
And you could then run two Dashers at the same time!
Dasher is not hunt-and-peck... I've just downloaded it and it's very clever! I think it would be much easier though with a stylus and not my laptop's finger-pad-thing!
Oh, and I can do 30wpm hunting and pecking quite easily.
Ouch.
What you are suggesting is not good for the database at all!
A decent database (even MySQL) can do LIKE matches on indexes.
The trick, as others have said, is to use caching. Lots of caching.
You may even want to put a Squid (or Apache 2.2) in front of your web server to catch these little requests and keep them away from your database.
Personally, I use MSN but am moving many friends and colleagues over to Skype. Skype is encrypted and also allows voice conversation. Excellent stuff.
Also look at the http://www.meebo.com/ site where you can use MSN/AIM/Yahoo/Jabber all at the same time over a web interface. Don't slashdot them!
So we're back to Usenet... finally!
Has anyone else noticed the trend to read RSS of blogs/forums in an application window- is rather similar to basic old Usenet of old?
You are correct to say XP was not very different to Win 2000 -- but a dud? No way. XP has been a resounding financial success for MS.
This is probably due to the advertising and corporate presence- Linux gets much less airtime even though for many users it is a far superior system.
While it is true PNG support in IE is not very good, there are lots of workarounds to get useful results.
Take a look at PNG blog entry where I linked to a page describing how to use transparent PNGs as backgrounds &c.
I completely agree with the above statement, but if you are using PostgreSQL for big Tb+ databases, the new 8.1 version has some partitioning-like features which will really help.
(I agree with many of the chap's comments about Mammoth skiing- I worked as a ski instructor there once... but Courchevel/les 3 Vallees in France is still so much better!)
Apache-group software is excellent, but can indeed be confusing. There is so much there of merit, which just isn't understood.
I use Apache 2 and don't get too concerned about the accompanying fluff; so long as I can configure it, it doesn't concern me. But woe betide the person who can't and has to go to apache.org and fight to get through the content there to what he actually needs!
I suspect 99.9% of Apache software used is the web server. Perhaps the Apache group has grown too far.
I also have a WL-500g Asus router- it's fantastic. Very reliable, with full Linux and USB.
I have disks and printers/scanners plugged in to mine.
Indeed- congratulations.
I'm using PostgreSQL for many things (custom app, Drupal, Apache logging, back-office) and it's great- this new release adds lots of useful bits.
Probably the most useful new feature for those who use it to run mini web sites will be the MAX() and MIN() functions now using indices- this has been a point of contention for some time.
XA will be useful for bigger stuff.
I'm also really pleased auto-vacuum is now part of the DB.
Now, Gentoo- let's get cracking!
Looks like you've been using DB2. However, once you're past the "connect to" bit, life improves.
Even a small child could understand SELECT toy FROM shop WHERE price 10.00 AND colour = 'blue'
True.
I just bought a couple of P3 800MHZ boxes, with 8GB disks and 256MB RAM for 40 UK pounds each (inc. postage) for a friend- rather overpowered for what I was going to use them for, but cheap as chips.
And I probably could have found a better deal somewhere else...
1000 pounds would buy you 25 of these: that's 20GHZ of P3 goodness in a cluster. Not that I would advise doing so, but for the price, these old boxes are fab.
That's an excellent idea.
To Mods- why on earth has my comment above been modded "flamebait"?????
Got to agree with you- VIEWS and triggers are great, but stored procedures are a real pain. However, they make triggers SO powerful (check out this blog entry on synchronising Apache passwords by one of the PostgreSQL developers).
I'd really like to know how you are supposed to edit stored procedures without programs like phppgadmin.
You should always use bound placeholders in SQL. Then you don't get SQL injection exploits.
i.e. define a parameter then execute: SELECT x FROM y WHERE p = '?'
It is also faster as the DB can use an already prepared query plan.
This is the ONLY way to write decent SQL applications?
The above post is accurate, but don't be confused and think "prepared SQL" is the same thing. Prepared SQL is similarly pre-parsed and pre-planned so you get decent performance benefits. And no chance of SQL injections hacks. (Why do so few people use prepared SQL? It's not complicated!)
Also bear in mind that a stored procedure could be *anything*. Postgres allows you to use perhaps half a dozen common languages; Oracle and DB2 similarly. I have no idea what MySQL allows- probably similar. You could write your whole application in the DB if you really wanted to.
Not to echo, but I made the switch and have never regretted it. Postgres is so much easier and more professional.
Very few (recent) comparisons around. From my experience, however, if you're running a simple web site with many SELECTs over a single table then MySQL may well suffice. If you're doing serious stuff with multiple table/view joins then you should move up a gear and use PostgreSQL.
I've moved completely to PostgreSQL (works beautifully on core Drupal too) and have found complex queries complete in a fraction of the time. I had a complicated application which had multiple threads inserting, updating and reading all at the same time- complete run-time was reduced to a tenth by using PostgreSQL.
It works for me- just make sure you use ADODB in PHP or Perl/DBI to make switching easy when you hit the MySQL limits.
One more thing: I work with serious mainframe DB2 during the day. MySQL just doesn't compare. Postgres feels closer.
The actual project was to do the ethernet audio stuff- I didn't want to play with DACs at all as they get VERY complicated VERY quickly. The PCM54s were rather nice chips, with a straightforward example use on the datasheet- having to faff around with opamps and resistors would have been fun for about two minutes but I wanted to get on with the challenging stuff :-)
Ah the days of 741 and 555s... when everything was simple...
I built a networked DAC a few years ago at university. Not too hard- the complex bit is making the timing and sync accurate, with the limitations of tiny chip controllers and rather unaccurate ethernet chip documentation!
Due to TCP/IP delays e.g. switching, you need some sort of buffering, which ends up meaning expensive memory on small chips. Once you have buffering e.g. 0.2 seconds, you should be fine. I ended up using a couple of little Burr-Brown PCM54 DACs, but the system was designed to feed digital into a decent professional DAC.
Disneyland Japan has had audio over ethernet for years as well; the setup there is huge, with hundreds of speakers over a large area.
There are good basic ethernet NAT units from e.g. Asus and Linksys.
Most do FTP, some do SSH. Watch out for overheating and buggy Samba installations.
I had a similar problem only this morning. I deleted all the rows from a table (by using DELETE FROM) and SELECT COUNT(*) went from sub-second to two minutes.
That's after going from 400,000 rows to zero.
VACUUM ANALYZE made no difference; however VACUUM FULL sorted it out. You should really have auto vacuum running, but for the dev I am doing I prefer to do it by hand.
From what you're saying, this could be the reason why it takes so long.
For what its worth, I've moved to Postgres because it's just so more solid. It's fantastic software. And I know what I'm talking about- I'm heavily involved in (big) mainframe DB2 at work.