Yet they must determine advantages of MyISAM over InnoDB over plain tables. For a newbie user of PostgreSQL, they can just create a table and be done with it.
Well if you are not experienced enough to make the difference between two table handlers, then you obviously won't be any more capable of using BEGIN/COMMIT/ROLLBACK correctly. Typing "TYPE=InnoDB" at the end of every CREATE TABLE is whithin any beginner reach, so I don't see why that would be a problem to someone who understand the concepts of ACID and the subtilities of transactions.
Once again, if it's important enough to store, it's important enough to protect.
That's absolutely wrong. Plenty of applications don't care about protecting what they store : caching systems, Web stats, etc. For all those, MySQL gives people the choice to use a non-ACID table handler (MyISAM) that is fast and simple. For everything else, there's InnoDB (ACID compliant, row level locking, etc.).
There's still an amazing array of critical applications that work in Cobol on systems that predates ACID relational databases. If you think doing payroll processing on non-ACID database is suicide, try to imagine what is sending rockets into space or controlling nuclear missile silos is in the 60s with systems that only support flat files...
Don't forget Israel didn't even existed 60 years ago. It was built on top of somebody's else land. And without that "somebody" agreement. In this regard I think you got your backyard analogy backward.
Real time encoding of high-res (768x576) TV programs in DivX 5.0. Not even a 2,8 Ghz P4 can handle this at full frame rate. 4,7 Ghz might be just powerfull enough for this.
Another thing that I'd like to see soon is foreign keys with integrity checking.
It's in already. You can use FOREIGN KEY constraints with "on update/on delete" events on them. Just use Innodb (the table handler that also does transactions and row level locking)
I'd have to agree here. Making an OS that is windows compatible (same API) means being able to reuse all the drivers and all the applications. It's a lot of work but even if that gets you 10% market share that's still more than enough to pay a hundred of engineers for the work. And then you don't have to worry about getting those freaking drivers anymore, so you save on driver developpment.
If all the work done on writting drivers for Linux had been put into writting an API layer to reuse Windows drivers, we would all enjoy more, better, faster drivers. But most Linux zealot would rather make fun of the Windows API and reinvent the wheel (without the hardware docs which are under NDA of course).
Quite rightly - frankly Lindows is a more than obvious shot at profiting from the fame of the name "Windows". Microsoft never sued Red Hat or Suse over their name...
I'm talking about query results. Some queries don't benefit much from data cache. Think about computing the average of a column on 100 million rows, with a 50 GB table. Most likely the rows won't fit in any data cache (and hence require to read the whole damn table no matter what), but the query result (one float) will fit easely into any query cache along with the query.
My site for example does charts based on a lot of rows. It's long to compute and read only, and yet the result set is small. That's a perfect job for a query cache.
Also while a data cache can cache data, it still requires you to do the computation. If you use regular expressions and other computational intensive requests the data cache is far less efficient than a query cache.
I disagree : MySQL replication is very easy to setup:
Stop updates on master database (unplug web server or other method of your choice)
Dump master database content into slave (mysqldump will do the job)
Edit my.cnf on slave and master (2 lines to add with vi)
Restart slave and master
Short of having a GUI with point and clic, you'll have a hard time getting it any easier. And from my testing it's very reliable as well (6 months working, no hicups)
Every major database on the market has a query cache (built in or optionnal). And that's because query cache is a good thing. Many web pages cannot be cached because they mix static and dynamic content. Here only a query cache can help. Also some queries are just plain slow to process no matter how good your database is, and there's no reason not to use a query cache here if the same query is run twice.
MySQL (or even Postgresql) don't claim to be drop-in replacement for DB2 or Oracle. But they claim to be good enough for simple database tasks, which happen to represent a huge share of the business market (for every high-availability banking application there are a 1000 small databases storing employee holidays, classroom affectation, etc.). These small databases are not only a bigger market in term of quantity (if not in value), but some of them also grow into big databases someday.
Remember when Microsoft was doing MS-DOS, no Unix vendors would have been worried, they had much better capabilities. When millions of PCs were sold with MS-DOS they started worrying. When Windows came out they growed gray hair. Now SQL Server and Windows Server have eaten the market of smaller servers and high-end workstation. This is the strategy of eating your way from the bottom to the top, and it will also work for MySQL and Postgresql : as time passes and as they mature they eat out an ever larger chunck of the database market.
Most people on a messageboard READ. They don't post. Only a fraction of readers also post, so that makes it a read intensive application - something where MySQL is good at. And if you are halfway a decent coder, you'd cache the generated page so that they are only generated once when somebody post something.
What kills the whole thing is messageboards who count the number of visits (how many times a thread have been red) or other small statistics : this require a huge amount of writes and kills the performance.
You can enforce relational integrity (foreign keys and "on delete"/"on update") are available in mysql 3.23 if you use the innodb table handler (which is good)
Actually MySQL does replication just fine (but it is only one way, there can only be one master). If you need few updates and huge amount of reads this allows you to spread the load amongst several servers.
That's a weakness PostgreSQL (which doesn't do any replication at all) should fix in a future release.
If we had done that Airbus (and it's about 50% market share) wouldn't exists nowadays. Why bother make our own plane if we can just buy some overpriced Boeings ?
True but I'm not really bitching about lack of hardware support (I can live with that), what bother's me is that all the attempt at "easy Linux" (easy installation and GUI) have all the same pitfalls : they are really nice looking front ends but don't go much further. Installation is easy AS LONG AS you install it on an "ordinary" PC with ordinary needs. KDE and Gnome are ok AS LONG AS you don't need to change anything that is hardware or system related.
In shorts, "easy Linux" distro are fine to make dumb terminals (a PC in a library you use to surf only) but all administration/maintenance tasks, even the most common ones, require you to leave the friendly GUI and venture into the darkest recesses of the OS. The problem is that any regular PC user, even my grandmother, needs sometimes to install a scanner or change her desktop screen refresh or resultion. And when that times comes, she discovers that Linux is not as user friendly as advertised. For comparison, I was amazed that installing a scanner on XP required me to plug the USB port and... that's all no drivers required, not even a single click necessary and it was available in Photoshop straight away.
The problem is that the 5% that is not identified cannot be installed or configured easely later on. Installing most distros is very easy as long as nothing goes wrong. As soon as something unexpected show up (or something expected doesn't show up) it's back to text files, howtos and command line again...
Well maybe Open source fans and companies could fund the campaign of a few senators. If Disney or Exxon can get "custom made" laws passed in return for their "generous contribution" we can do the same. It's been a long time that US politicians are sold to the highest bidder...
Slashdot Mirror
Yet they must determine advantages of MyISAM over InnoDB over plain tables. For a newbie user of PostgreSQL, they can just create a table and be done with it.
Well if you are not experienced enough to make the difference between two table handlers, then you obviously won't be any more capable of using BEGIN/COMMIT/ROLLBACK correctly. Typing "TYPE=InnoDB" at the end of every CREATE TABLE is whithin any beginner reach, so I don't see why that would be a problem to someone who understand the concepts of ACID and the subtilities of transactions.
Once again, if it's important enough to store, it's important enough to protect.
That's absolutely wrong. Plenty of applications don't care about protecting what they store : caching systems, Web stats, etc. For all those, MySQL gives people the choice to use a non-ACID table handler (MyISAM) that is fast and simple. For everything else, there's InnoDB (ACID compliant, row level locking, etc.).
Well,MySQL supports foreign keys (for use in joins, etc.) but fails to support any mechanism of enforcing referential integrity.
You are wrong. With the InnoDB table handler the foreign key integrity is also enforced automatically inside MySQL.
If it's important enough to store, it's important enough to protect. ACID is not optional.
Since MySQL is ACID what's your point here ?
There's still an amazing array of critical applications that work in Cobol on systems that predates ACID relational databases. If you think doing payroll processing on non-ACID database is suicide, try to imagine what is sending rockets into space or controlling nuclear missile silos is in the 60s with systems that only support flat files...
They run PHP Accelerator, which is as fast but free :)
Don't forget Israel didn't even existed 60 years ago. It was built on top of somebody's else land. And without that "somebody" agreement. In this regard I think you got your backyard analogy backward.
Real time encoding of high-res (768x576) TV programs in DivX 5.0. Not even a 2,8 Ghz P4 can handle this at full frame rate. 4,7 Ghz might be just powerfull enough for this.
Another thing that I'd like to see soon is foreign keys with integrity checking.
It's in already. You can use FOREIGN KEY constraints with "on update/on delete" events on them. Just use Innodb (the table handler that also does transactions and row level locking)
I'd have to agree here. Making an OS that is windows compatible (same API) means being able to reuse all the drivers and all the applications. It's a lot of work but even if that gets you 10% market share that's still more than enough to pay a hundred of engineers for the work. And then you don't have to worry about getting those freaking drivers anymore, so you save on driver developpment.
If all the work done on writting drivers for Linux had been put into writting an API layer to reuse Windows drivers, we would all enjoy more, better, faster drivers. But most Linux zealot would rather make fun of the Windows API and reinvent the wheel (without the hardware docs which are under NDA of course).
Quite rightly - frankly Lindows is a more than obvious shot at profiting from the fame of the name "Windows". Microsoft never sued Red Hat or Suse over their name...
1) Be wealthy
This is enough in the US. Step 2) and 3) or not required.
I'm talking about query results. Some queries don't benefit much from data cache. Think about computing the average of a column on 100 million rows, with a 50 GB table. Most likely the rows won't fit in any data cache (and hence require to read the whole damn table no matter what), but the query result (one float) will fit easely into any query cache along with the query.
My site for example does charts based on a lot of rows. It's long to compute and read only, and yet the result set is small. That's a perfect job for a query cache.
Also while a data cache can cache data, it still requires you to do the computation. If you use regular expressions and other computational intensive requests the data cache is far less efficient than a query cache.
Short of having a GUI with point and clic, you'll have a hard time getting it any easier. And from my testing it's very reliable as well (6 months working, no hicups)
Every major database on the market has a query cache (built in or optionnal). And that's because query cache is a good thing. Many web pages cannot be cached because they mix static and dynamic content. Here only a query cache can help. Also some queries are just plain slow to process no matter how good your database is, and there's no reason not to use a query cache here if the same query is run twice.
You can do the same without the NTFS file encryption built into 2000 Pro and XP Pro...
MySQL (or even Postgresql) don't claim to be drop-in replacement for DB2 or Oracle. But they claim to be good enough for simple database tasks, which happen to represent a huge share of the business market (for every high-availability banking application there are a 1000 small databases storing employee holidays, classroom affectation, etc.). These small databases are not only a bigger market in term of quantity (if not in value), but some of them also grow into big databases someday.
Remember when Microsoft was doing MS-DOS, no Unix vendors would have been worried, they had much better capabilities. When millions of PCs were sold with MS-DOS they started worrying. When Windows came out they growed gray hair. Now SQL Server and Windows Server have eaten the market of smaller servers and high-end workstation. This is the strategy of eating your way from the bottom to the top, and it will also work for MySQL and Postgresql : as time passes and as they mature they eat out an ever larger chunck of the database market.
Most people on a messageboard READ. They don't post. Only a fraction of readers also post, so that makes it a read intensive application - something where MySQL is good at. And if you are halfway a decent coder, you'd cache the generated page so that they are only generated once when somebody post something.
What kills the whole thing is messageboards who count the number of visits (how many times a thread have been red) or other small statistics : this require a huge amount of writes and kills the performance.
You can enforce relational integrity (foreign keys and "on delete"/"on update") are available in mysql 3.23 if you use the innodb table handler (which is good)
Actually MySQL does replication just fine (but it is only one way, there can only be one master). If you need few updates and huge amount of reads this allows you to spread the load amongst several servers.
That's a weakness PostgreSQL (which doesn't do any replication at all) should fix in a future release.
If we had done that Airbus (and it's about 50% market share) wouldn't exists nowadays. Why bother make our own plane if we can just buy some overpriced Boeings ?
Oh well, that's strange because I just did it several months ago (and then just did ./configure, make, make install to get it working)
True but I'm not really bitching about lack of hardware support (I can live with that), what bother's me is that all the attempt at "easy Linux" (easy installation and GUI) have all the same pitfalls : they are really nice looking front ends but don't go much further. Installation is easy AS LONG AS you install it on an "ordinary" PC with ordinary needs. KDE and Gnome are ok AS LONG AS you don't need to change anything that is hardware or system related.
In shorts, "easy Linux" distro are fine to make dumb terminals (a PC in a library you use to surf only) but all administration/maintenance tasks, even the most common ones, require you to leave the friendly GUI and venture into the darkest recesses of the OS. The problem is that any regular PC user, even my grandmother, needs sometimes to install a scanner or change her desktop screen refresh or resultion. And when that times comes, she discovers that Linux is not as user friendly as advertised. For comparison, I was amazed that installing a scanner on XP required me to plug the USB port and... that's all no drivers required, not even a single click necessary and it was available in Photoshop straight away.
The problem is that the 5% that is not identified cannot be installed or configured easely later on. Installing most distros is very easy as long as nothing goes wrong. As soon as something unexpected show up (or something expected doesn't show up) it's back to text files, howtos and command line again...
You are confused. Delphi/Kylix used Object Pascal and is fully object. There's no problem mapping it to C++ or the other way around.
Well maybe Open source fans and companies could fund the campaign of a few senators. If Disney or Exxon can get "custom made" laws passed in return for their "generous contribution" we can do the same. It's been a long time that US politicians are sold to the highest bidder...