I don't think that you know Oracle very well. Lets say you want so scale and so you want clustering or grid functionality -- built into Oracle. Lets say that you want to partition your enormous table into one physical table per month or quarter -- built in. Oh, and if you query the whole giant table you'd like parallel processes to run against each partition, balanced across your cluster or grid -- yeah, that's built in too. Lets say you almost always get a group of data together rather than piece by piece so you want it physically colocated to reduce disk i/o -- built in.
This is why you pay a good wage for your Oracle data architect & DBA -- so that you can get people who know how to do these sort of things when needed. And honestly I'm not even scratching the surface.
Consider a data warehouse for a giant telecom in South Africa (with a DBA named Billy in case you wondered). You have over a billion rows in your main fact table, but you're only interested in a few thousand of those rows. You have an index on dates and another index on geographic region and another region on customer. Any one of those indexes will reduce the 1.1 billion rows to 10's of millions of rows, but all three restrictions will reduce it to a few thousand. What if you could read three indexes, perform bitmap comparisons on the results to get only the rows that match the results of all three indexes and then only fetch those few thousand rows from the 1.1 billion row table. Yup, that's built in and Oracle does it for you for behind the scenes.
Now yeah, you can build a faster single-purpose db. But you better have a god damn'd lot of dev hours allocated to the task. My bet is that you'll probably come our way ahead in cash & time to market with Oracle, a good data architect and a good DBA. Any time you want to put your money on the line, you let me know.
Primarily, you avoid the situation where you call Red Hat support and they tell you that the problem is with Oralce, and then (wait for it, wait for it...) you call Oracle and they tell you that the problem is with Red Hat. If you can call one company and know that they'll take responsibility for your problem then that's a no brainer.
There's no kind way to say this, but you have no perspective on this. It is very, very common for a single db to have endured from C/C++ through RAD client-server through J2EE,.NET, whatever. The data matters more to most companies than the applications do. The applications come and go, but the database typically endures.
Re:Definitely has uses but..
on
Oracle Linux?
·
· Score: 2, Informative
I'm not sure what you're refering to when you talk about "wierd extra things enabled." Here are some reasonable changes you'll want to make to/etc/sysctl.conf
Executives' salaries/benefits commonly are strongly tied to the profitability of the corporation. I've never heard of an executive's pay being tied to the morality of the corporation's policies. Hence, corporations are amoral. Greed is not an ethical impulse.
It was Bush that insisted the levies were over-funded and cut the budget for their maintenance. And it was Bush that decided that FEMA was just pork barrel spending and replaced their career professionals with political appointees without any relevant experience.
As far as blame for the levy failures, there's plenty to go around. The city didn't want to use enough land to build levies as wide & strong as the Army Corp indicated were necessary. That would have entailed destroying more peoples' houses under emminent domain and was about as politically popular as emminent domain almost always ends up being.
Linux' ability to run proprietary software such as an Oracle database is essential to its success. How is this any different?
Re:probably on Microsoft's list of next important
on
Apache down, IIS up
·
· Score: 1
You do realized that you're paraphrasing a Nazi in your sig, don't you? "Whenever I hear the word culture, I reach for my revolver." -- Goering
Re:Useless to all but theoraticians
on
The Art of SQL
·
· Score: 2, Insightful
If you're worried about syntax variations across databases, then this is clearly not the book for you. However, once you're past syntax you need a book like this -- and I haven't seen another like it. The author is talking about how SQL works. What's the implication of using a correlated-IN clause vs. a correlated-EXISTS clause? Regardless of the syntax of a particular SQL dialect it is crucial that you understand these sorts of things unless you want to stare at the db blindly and wonder why it's slow.
Re:Bummer, trees
on
The Art of SQL
·
· Score: 2, Informative
Didn't look at the sample chapter, did you? It deals with a many-many relation several times in varying contexts.
the sample chapter is promising
on
The Art of SQL
·
· Score: 2, Informative
I like the look of this book quite a bit, judging soley from the sample chapter. It talks in a straight-forward manner about the factors that determine how a database goes about it's job and how you can make that job easier or harder. If the rest of the book plays out similarly then thorough understanding of this book as well as Tom Kyte's would make for a programmer I'd love to hire.
Oracle costs a fair bit. Their pricing has finally come more in line for mid-size installations, but still it ain't cheap. So why spend that cash?
1. You can find experienced developers and DBAs who live and breathe best-practices. 2. DBAs and developers cost money too. A developer is so much more productive in PL/SQL (Oracle's stored procedure language is a real language, not a shell script running in the db) that once you have 6 or so full time database developers Oracle pays for itself in developer productivity. It really is comparable paying licensing fees to code in Java or C# vs. coding in ksh for free. 3. There is an enormous, in-depth Oracle knowledge base to draw on, both on-line and as authors. I can get any question resolved frighteningly quickly at asktom.oracle.com or http://www.quest-pipelines.com/pipelines/dba/index .asp or forums.oracle.com or www.dizwell.com/forum or...
In short, I have much better tools, much better support and a much deeper knowledge base to draw on.
On the plus side of PostgreSQL, recently I had to resolve a SQL Server issue that simply brought the db to its knees. The solution was to not use large (10k to 100k rows) transactions. PostgreSQL has an entirely sensible concurrency/transaction model and does not have the same aweful issues.
Has anyone assessed the multi-versioned data that MS built into this version of SQL Server? This has always been the single feature that has left certain databases (mysql, sql server) incapable of scaling up to large numbers of transactions, while others (oracle, postgresql) have no such issues.
Essentially, each sql statement (or transaction) gets its own point-in-time image of the data constructed for it. In Oracle and PG this "consistent" image of the data is constructed by reference to the transaction logs. My statements starts when the transaction counter (SCN on Oracle) is 12345 -- I will only get images of the data with a transaction counter of 12345. This means that my debits & credits always match as long as they're entered in the same transaction. This means that I can include dozens of small dml statements in my transaction because I'm not blocking anybody -- they all have consistent images of the data too.
Oracle does this in a blazingly fast manner -- and so scales in a manner that occasionally makes grown men weap. So I ask again, y'all looked at this one, key new feature?
where he references the conflict on the right between old-time religion and big-time business. Prediction: cash beats out credo.
"Ennis points out that bio-technology is rapidly becoming a very lucrative field. Those who understand modern biology will reap the benefits. Those who think the planet is 6,000 years old and that dinosaurs and humans lived at the same time will be left behind working at Wal-Mart and watching 'The Flintstones.'"
"We shall not flag nor fail. We shall go on to the end. We shall fight in France and on the seas and oceans; we shall fight with growing confidence and growing strength in the air. We shall defend our island whatever the cost may be; we shall fight on beaches, landing grounds, in fields, in streets and on the hills. We shall never surrender and even if, which I do not for the moment believe, this island or a large part of it were subjugated and starving, then our empire beyond the seas, armed and guarded by the British Fleet, will carry on the struggle until in God's good time the New World with all its power and might, sets forth to the liberation and rescue of the Old."
It's not uncommon for some conferences to intentionally accept any submissions. They typically cost quite a bit, are in attractive vacation locations, and will accept anyone. The "researcher" gets a free vacation (on the research institute's dime) and the "conference" gets the conference fees. Another variant involves fake conferences that exist solely to generate dues and allow their international attendees to get visas to the U.S. Once in the U.S. the attendees are often never heard from again.
There have been three great, head and shoulders above the rest, mathematicians: Archimedes, Newton and Gauss. If you don't know who these men were and what they did, well, then you probably shouldn't be talking about mathematicians in a very knowing manner. Just saying.
The money that comes into Social Security comes from the payroll deductions of current workers. If you divert all of this to individual accounts then you must either end SS payments to current retirees or borrow enough to cover all of their promised payments.
On the topic of privatizing SS, the UK has had no end of trouble here. The investment fees eat up more than the investments gain. You have to remember that SS deductions go up with payroll increases. By and large payroll increases with growth in the economy (inflation + productivity gains). This means that investments must beat (inflation + productivity). Investments are (inflation + equity premium - fees). Now the equity premium is (productivity + expectation of wealth gained). So you're arguing that the general expectation of stocks' growth will consistently be higher than the fees. Historically you won't fare terribly well on this bet.
The UK is currently working to de-privatize their Thatcher era pension reforms because of the troubles it has caused. And Argentina didn't work out nearly so well as the UK did.
If we do nothing to SS then sometime around 2042 it will run out of its accumulated funds and only pay out what it takes in. This amounts to roughly 70% of what has been promised to folk -- not good, but not disasterous. Privatization does _nothing_ to offset this. To offset this you must do something like:
Raise the eligibility age
Increase SS payroll deductions
Decrease payouts
The Bush administration is promoting door number 3. They propose indexing SS payments to cost of living increases rather than to payroll. Because cost of living = inflation, and as noted above, payroll = inflation + productivity, this means that all gains in productivity are taken away from SS payments. Over the life of SS this amounts to a 75% reduction in payments, say from $3000 down to $750. This is another way to end SS by over the long run reducing its value to nearly nothing. That is, in my opinion, the goal of the current Bush effort -- the elimination of SS.
Then we ask who the winners are under such a scenario. The clear answer is the folk who collect the investment fees, above. These folk are, not surprisingly, funding the Bush inauguration quite generously.
It is also important to realize that SS payroll deductions are taken out of the first $75,000 that folk earn at a flat rate of 12.6%. This makes it a highly regressive tax -- in that the wealthy pay very little SS tax. If we then turn around and reduce payments from SS we have effectively found a way to take the poor and middle class, while giving them less for their investment.
Maybe folk will cry sexism when they read redneck comments like "fat bull-dyke."
And the fact that men in video games are attractive is _not_ the same thing as the objectification of women in video games. The women are not simply attractive, they are highly sexualized. If the male characters were that sexualized the whole thing would look like a cliche gay bar. The crucial point, however, is that the objectification of women by men is a very concrete manifestation of patriarchy -- it is a manifestation of the power position that men hold over women. Men are almost never threatened when women objectify then, the reverse is commonly true.
Encouraging, and in fact reveling in the privilege men possess is ugly. Using it to market to men is beyond amoral as far as I'm concerned.
Scott
P.S. The term is "no one," there is no such word as noone.
How much lab equiptment do you need in order to say "I don't understand, therefor God?" Mmmm, lets all call that science, shall we? I'm stealing Bradford DeLong's words, but I'm counting on folk around here not reading economists too much.
Slashdot Mirror
I don't think that you know Oracle very well. Lets say you want so scale and so you want clustering or grid functionality -- built into Oracle. Lets say that you want to partition your enormous table into one physical table per month or quarter -- built in. Oh, and if you query the whole giant table you'd like parallel processes to run against each partition, balanced across your cluster or grid -- yeah, that's built in too. Lets say you almost always get a group of data together rather than piece by piece so you want it physically colocated to reduce disk i/o -- built in.
This is why you pay a good wage for your Oracle data architect & DBA -- so that you can get people who know how to do these sort of things when needed. And honestly I'm not even scratching the surface.
Consider a data warehouse for a giant telecom in South Africa (with a DBA named Billy in case you wondered). You have over a billion rows in your main fact table, but you're only interested in a few thousand of those rows. You have an index on dates and another index on geographic region and another region on customer. Any one of those indexes will reduce the 1.1 billion rows to 10's of millions of rows, but all three restrictions will reduce it to a few thousand. What if you could read three indexes, perform bitmap comparisons on the results to get only the rows that match the results of all three indexes and then only fetch those few thousand rows from the 1.1 billion row table. Yup, that's built in and Oracle does it for you for behind the scenes.
Now yeah, you can build a faster single-purpose db. But you better have a god damn'd lot of dev hours allocated to the task. My bet is that you'll probably come our way ahead in cash & time to market with Oracle, a good data architect and a good DBA. Any time you want to put your money on the line, you let me know.
Primarily, you avoid the situation where you call Red Hat support and they tell you that the problem is with Oralce, and then (wait for it, wait for it...) you call Oracle and they tell you that the problem is with Red Hat. If you can call one company and know that they'll take responsibility for your problem then that's a no brainer.
There's no kind way to say this, but you have no perspective on this. It is very, very common for a single db to have endured from C/C++ through RAD client-server through J2EE, .NET, whatever. The data matters more to most companies than the applications do. The applications come and go, but the database typically endures.
I'm not sure what you're refering to when you talk about "wierd extra things enabled." Here are some reasonable changes you'll want to make to /etc/sysctl.conf
kernel.shmall = 2097152
kernel.shmmax = 2147483648
kernel.shmmni = 4096
kernel.sem = 250 32000 100 128
fs.file-max = 65536
net.ipv4.ip_local_port_range = 1024 65000
net.core.rmem_default = 262144
net.core.wmem_default = 262144
net.core.rmem_max = 262144
And then you'll need async i/o.
yum install libaio
The above all taken from HJR -- www.dizwell.com > installation guides
net.core.wmem_max = 262144
Executives' salaries/benefits commonly are strongly tied to the profitability of the corporation. I've never heard of an executive's pay being tied to the morality of the corporation's policies. Hence, corporations are amoral. Greed is not an ethical impulse.
It was Bush that insisted the levies were over-funded and cut the budget for their maintenance. And it was Bush that decided that FEMA was just pork barrel spending and replaced their career professionals with political appointees without any relevant experience.
As far as blame for the levy failures, there's plenty to go around. The city didn't want to use enough land to build levies as wide & strong as the Army Corp indicated were necessary. That would have entailed destroying more peoples' houses under emminent domain and was about as politically popular as emminent domain almost always ends up being.
Linux' ability to run proprietary software such as an Oracle database is essential to its success. How is this any different?
You do realized that you're paraphrasing a Nazi in your sig, don't you? "Whenever I hear the word culture, I reach for my revolver." -- Goering
If you're worried about syntax variations across databases, then this is clearly not the book for you. However, once you're past syntax you need a book like this -- and I haven't seen another like it. The author is talking about how SQL works. What's the implication of using a correlated-IN clause vs. a correlated-EXISTS clause? Regardless of the syntax of a particular SQL dialect it is crucial that you understand these sorts of things unless you want to stare at the db blindly and wonder why it's slow.
Didn't look at the sample chapter, did you? It deals with a many-many relation several times in varying contexts.
I like the look of this book quite a bit, judging soley from the sample chapter. It talks in a straight-forward manner about the factors that determine how a database goes about it's job and how you can make that job easier or harder. If the rest of the book plays out similarly then thorough understanding of this book as well as Tom Kyte's would make for a programmer I'd love to hire.
Oracle costs a fair bit. Their pricing has finally come more in line for mid-size installations, but still it ain't cheap. So why spend that cash?
x .asp or forums.oracle.com or www.dizwell.com/forum or ...
1. You can find experienced developers and DBAs who live and breathe best-practices.
2. DBAs and developers cost money too. A developer is so much more productive in PL/SQL (Oracle's stored procedure language is a real language, not a shell script running in the db) that once you have 6 or so full time database developers Oracle pays for itself in developer productivity. It really is comparable paying licensing fees to code in Java or C# vs. coding in ksh for free.
3. There is an enormous, in-depth Oracle knowledge base to draw on, both on-line and as authors. I can get any question resolved frighteningly quickly at asktom.oracle.com or http://www.quest-pipelines.com/pipelines/dba/inde
In short, I have much better tools, much better support and a much deeper knowledge base to draw on.
On the plus side of PostgreSQL, recently I had to resolve a SQL Server issue that simply brought the db to its knees. The solution was to not use large (10k to 100k rows) transactions. PostgreSQL has an entirely sensible concurrency/transaction model and does not have the same aweful issues.
Cheers,
Scott
Has anyone assessed the multi-versioned data that MS built into this version of SQL Server? This has always been the single feature that has left certain databases (mysql, sql server) incapable of scaling up to large numbers of transactions, while others (oracle, postgresql) have no such issues.
Essentially, each sql statement (or transaction) gets its own point-in-time image of the data constructed for it. In Oracle and PG this "consistent" image of the data is constructed by reference to the transaction logs. My statements starts when the transaction counter (SCN on Oracle) is 12345 -- I will only get images of the data with a transaction counter of 12345. This means that my debits & credits always match as long as they're entered in the same transaction. This means that I can include dozens of small dml statements in my transaction because I'm not blocking anybody -- they all have consistent images of the data too.
Oracle does this in a blazingly fast manner -- and so scales in a manner that occasionally makes grown men weap. So I ask again, y'all looked at this one, key new feature?
Cheers,
Scott
Your post reminds me of a post from the carpetbagger
1 .html
http://www.thecarpetbaggerreport.com/archives/404
where he references the conflict on the right between old-time religion and big-time business. Prediction: cash beats out credo.
"Ennis points out that bio-technology is rapidly becoming a very lucrative field. Those who understand modern biology will reap the benefits. Those who think the planet is 6,000 years old and that dinosaurs and humans lived at the same time will be left behind working at Wal-Mart and watching 'The Flintstones.'"
"We shall not flag nor fail. We shall go on to the end. We shall fight in France and on the seas and oceans; we shall fight with growing confidence and growing strength in the air. We shall defend our island whatever the cost may be; we shall fight on beaches, landing grounds, in fields, in streets and on the hills. We shall never surrender and even if, which I do not for the moment believe, this island or a large part of it were subjugated and starving, then our empire beyond the seas, armed and guarded by the British Fleet, will carry on the struggle until in God's good time the New World with all its power and might, sets forth to the liberation and rescue of the Old."
It's not uncommon for some conferences to intentionally accept any submissions. They typically cost quite a bit, are in attractive vacation locations, and will accept anyone. The "researcher" gets a free vacation (on the research institute's dime) and the "conference" gets the conference fees. Another variant involves fake conferences that exist solely to generate dues and allow their international attendees to get visas to the U.S. Once in the U.S. the attendees are often never heard from again.
You forgot the shark link.
There have been three great, head and shoulders above the rest, mathematicians: Archimedes, Newton and Gauss. If you don't know who these men were and what they did, well, then you probably shouldn't be talking about mathematicians in a very knowing manner. Just saying.
No, it tastes like your momma's cell phone. And I should know.
Is that you President Bush?
They're a coalition of center-right bloggers. Smart folk -- and I'm an old fashioned lefty.
http://www.deadparrots.net/
Step 4.5 Include, absolutely free, at no cost to you, Ginsu(tm) knives!
On the topic of privatizing SS, the UK has had no end of trouble here. The investment fees eat up more than the investments gain. You have to remember that SS deductions go up with payroll increases. By and large payroll increases with growth in the economy (inflation + productivity gains). This means that investments must beat (inflation + productivity). Investments are (inflation + equity premium - fees). Now the equity premium is (productivity + expectation of wealth gained). So you're arguing that the general expectation of stocks' growth will consistently be higher than the fees. Historically you won't fare terribly well on this bet.
The UK is currently working to de-privatize their Thatcher era pension reforms because of the troubles it has caused. And Argentina didn't work out nearly so well as the UK did.
If we do nothing to SS then sometime around 2042 it will run out of its accumulated funds and only pay out what it takes in. This amounts to roughly 70% of what has been promised to folk -- not good, but not disasterous. Privatization does _nothing_ to offset this. To offset this you must do something like:
The Bush administration is promoting door number 3. They propose indexing SS payments to cost of living increases rather than to payroll. Because cost of living = inflation, and as noted above, payroll = inflation + productivity, this means that all gains in productivity are taken away from SS payments. Over the life of SS this amounts to a 75% reduction in payments, say from $3000 down to $750. This is another way to end SS by over the long run reducing its value to nearly nothing. That is, in my opinion, the goal of the current Bush effort -- the elimination of SS.
Then we ask who the winners are under such a scenario. The clear answer is the folk who collect the investment fees, above. These folk are, not surprisingly, funding the Bush inauguration quite generously.
It is also important to realize that SS payroll deductions are taken out of the first $75,000 that folk earn at a flat rate of 12.6%. This makes it a highly regressive tax -- in that the wealthy pay very little SS tax. If we then turn around and reduce payments from SS we have effectively found a way to take the poor and middle class, while giving them less for their investment.
Cheers,
Scott
Maybe folk will cry sexism when they read redneck comments like "fat bull-dyke."
And the fact that men in video games are attractive is _not_ the same thing as the objectification of women in video games. The women are not simply attractive, they are highly sexualized. If the male characters were that sexualized the whole thing would look like a cliche gay bar. The crucial point, however, is that the objectification of women by men is a very concrete manifestation of patriarchy -- it is a manifestation of the power position that men hold over women. Men are almost never threatened when women objectify then, the reverse is commonly true.
Encouraging, and in fact reveling in the privilege men possess is ugly. Using it to market to men is beyond amoral as far as I'm concerned.
Scott
P.S. The term is "no one," there is no such word as noone.
S.
How much lab equiptment do you need in order to say "I don't understand, therefor God?" Mmmm, lets all call that science, shall we? I'm stealing Bradford DeLong's words, but I'm counting on folk around here not reading economists too much.
Cheers,
Scott