Understanding the relational model is important, but performance-wise it's also very important to understand the inner workings of the concrete implementations of RDBMS you'll find out there.
Unfortunatelly, most developers know nil out of dbms. They don't understand how data is stored, how indexes work, why you have all those logs, what are the main different concurrency protocols used by different databases, they don't understand how buffer caches are used and so on.
As an anedocte, once I've heard an history about someone who could not come with a counter argument for the idea that distributed caches like memacached or hibernate could not offer any advantage because if you give more memory to your dbms it would cache it anyway in memory. Well, the bottom line is that the developer thought memcached was cool(and it is), and Oracle is a piece of trash (it's not) but could not explain why that Oracle kept *blocks* on buffer caches, not objects, or individual rows, that Oracle had to maintain consistency (what memcached is not concerned with) and because of it there was merit of using a distributed cache for mostly-read-only data behind the webservers. So what is the problem here? We have tools that isolate most of the things that were the concern of programmers of ancient ages like middleware, distributed transaction controllers, dbms, garbage collection, but most programmers have forgotten, or have never learned, what those tools have to do behind the scenes, I am not advocating that everyone should be able to implement an OS, or a dbms system, a compiler or a garbage collection module for a VM, but instead, that people should be acquainted with the fundamental problems that exists on the system level, that every programmer should not see the computer as a black box, but that he should understand some fundamental things on the system level.
And it's not only the fault of the programmers. As DBAs became more and more specialized, they understand less and less of programming, and thus are sometimes unable to understand simple things, because they don't see their DBMS under a programmer's point of view, and thus with all those point and click management interfaces they have no idea of why things like having a low page density on SQL Server table leads to bad performance on reads.
I've seen it too many times: People with lots of certifications but that would not understand how Virtual Memory works, and thus would configure their systems on the worst possible way. People who procured large multi-core system but that have no idea of how Ahmdal's law would broke their dreams of linear performance improvements on pieces. People who could not believe that IO is terribly slow, and that because of that could not believe that putting a lot of log statements in their production code would waste most of the available processor time waiting on IO.
Those things may not look like very much important on the short run, you can get away with horribly optimized code for most of the time. The trouble is: Ignoring performance will hurt your businness on the worst of the circunstances, in the christmas period for a retail chain, on vacations time for a airline reservation system and so on.
I know that Dijkstra said that "Early Optimization is the root of all evil" and I agree with him. But I humbly must add a phrase of mine:
"Reckless regard for optimization is the cube of all evil" Marcos Eliziario - Brazilian-Joe-Nobody(1974- )
From someone who has been there, done that. I can say that throwing hardware at a problem rarely works. If nothing else, faster hardware tend to increase the advantage of good algorithms over poorer ones. Say I have an alghorithm who runs at O(N) and another one functionally equivalent that runs at O(N^2). Now let's say that you need to double the size of the input keeping the execution time constant. For the first algorithm you will need a machine which is 2X faster than the current one, for the second O(N^2) you'll need a 10X times faster machine. Let's not forget that you need not only things to run fast, but to run correctly, and the absurdity of choosing less skilled programmers with more expensive hardware will become painfully evident.
PS: Sorry for the typos and other errors: english is not my native language, and I've got a bit too much beer last night.
Better yet. If people in your office share your irrational mistrust of cable-locks, put a Rotweiller on your cubicle, and tie him with one of those locks.
Actually he was Jew in Soviet Union, and somewhat managed to have a scientific career, suffered the implosion of the USSR, flewd to Israel, and it took him a lot of time to find a job as a professor there, so in the meanwhile he had to work as a security guard to put food on his table. But at the time he wrote the proof he already had gotten a job.
Of course, his acchievements prove that he is not a loser like those bastards who can't even RTFA before posting.
Btw, I believe that one thing that could ruin the social environment inside a space ship is some bastard jerking off without using the vacuum device. I am sure this is a thing that probably is covered somewhere on astronaut's operational handbooks.
Slashdot Mirror
Understanding the relational model is important, but performance-wise it's also very important to understand the inner workings of the concrete implementations of RDBMS you'll find out there.
Unfortunatelly, most developers know nil out of dbms. They don't understand how data is stored, how indexes work, why you have all those logs, what are the main different concurrency protocols used by different databases, they don't understand how buffer caches are used and so on. As an anedocte, once I've heard an history about someone who could not come with a counter argument for the idea that distributed caches like memacached or hibernate could not offer any advantage because if you give more memory to your dbms it would cache it anyway in memory. Well, the bottom line is that the developer thought memcached was cool(and it is), and Oracle is a piece of trash (it's not) but could not explain why that Oracle kept *blocks* on buffer caches, not objects, or individual rows, that Oracle had to maintain consistency (what memcached is not concerned with) and because of it there was merit of using a distributed cache for mostly-read-only data behind the webservers. So what is the problem here? We have tools that isolate most of the things that were the concern of programmers of ancient ages like middleware, distributed transaction controllers, dbms, garbage collection, but most programmers have forgotten, or have never learned, what those tools have to do behind the scenes, I am not advocating that everyone should be able to implement an OS, or a dbms system, a compiler or a garbage collection module for a VM, but instead, that people should be acquainted with the fundamental problems that exists on the system level, that every programmer should not see the computer as a black box, but that he should understand some fundamental things on the system level.
And it's not only the fault of the programmers. As DBAs became more and more specialized, they understand less and less of programming, and thus are sometimes unable to understand simple things, because they don't see their DBMS under a programmer's point of view, and thus with all those point and click management interfaces they have no idea of why things like having a low page density on SQL Server table leads to bad performance on reads. I've seen it too many times: People with lots of certifications but that would not understand how Virtual Memory works, and thus would configure their systems on the worst possible way. People who procured large multi-core system but that have no idea of how Ahmdal's law would broke their dreams of linear performance improvements on pieces. People who could not believe that IO is terribly slow, and that because of that could not believe that putting a lot of log statements in their production code would waste most of the available processor time waiting on IO.
Those things may not look like very much important on the short run, you can get away with horribly optimized code for most of the time. The trouble is: Ignoring performance will hurt your businness on the worst of the circunstances, in the christmas period for a retail chain, on vacations time for a airline reservation system and so on.
I know that Dijkstra said that "Early Optimization is the root of all evil" and I agree with him. But I humbly must add a phrase of mine:
"Reckless regard for optimization is the cube of all evil"
Marcos Eliziario - Brazilian-Joe-Nobody(1974- )
And if you are microsoft, make your users think it's normal to throw hardware at it. After all, it's their money, not yours.
From someone who has been there, done that. I can say that throwing hardware at a problem rarely works.
If nothing else, faster hardware tend to increase the advantage of good algorithms over poorer ones.
Say I have an alghorithm who runs at O(N) and another one functionally equivalent that runs at O(N^2). Now let's say that you need to double the size of the input keeping the execution time constant. For the first algorithm you will need a machine which is 2X faster than the current one, for the second O(N^2) you'll need a 10X times faster machine.
Let's not forget that you need not only things to run fast, but to run correctly, and the absurdity of choosing less skilled programmers with more expensive hardware will become painfully evident.
PS: Sorry for the typos and other errors: english is not my native language, and I've got a bit too much beer last night.
No problem, he must be already used to type google.com when he wants to do a search. After all, who would search in yahoo?
+5 DIY-EASY-AND-FUN
how are the prices going for vintage beer? I really hope at least is not one of those shitty Budweisers you americans dare to drink.
Of course, he is not that worried. He is just being a bitch because he lost his private office.
Better yet. If people in your office share your irrational mistrust of cable-locks, put a Rotweiller on your cubicle, and tie him with one of those locks.
Ops. my bad. sorry.
Actually he was Jew in Soviet Union, and somewhat managed to have a scientific career, suffered the implosion of the USSR, flewd to Israel, and it took him a lot of time to find a job as a professor there, so in the meanwhile he had to work as a security guard to put food on his table. But at the time he wrote the proof he already had gotten a job.
Of course, his acchievements prove that he is not a loser like those bastards who can't even RTFA before posting.
Huahuahauahuahauaa. Thought the same....
This episode should have an article on wikipedia.
Tell him to send his resume to my organization, we're always hiring managers.
Actually I think that this idea comes directly from Thoreau.
"Under a government which imprisons any unjustly, the true place for a just
man is also a prison." Henry David Thoreau
Well... if you want to archive something to an email account, I believe that outgoing packets to an SMTP server are what you'd expect.
So, if you live in TX where gun laws are pretty much liberal, would u probably feel the urge to buy an ICBM just to stay on the illegal side? ;-)
At least buying iphone is not as humiliating as buying a motorola razrs. So, look! things are improving!
And Apple Computers has always been in peace with Intel Corp.
Yes, I live in the same country as you, but what really sucks here is the tax over new SUV Space Ships.
The concepts of data, storage and online are somewhat confused in the mind of the average user.
Although an unusual tone for a blues song.
Blood for plutonium?
Btw, I believe that one thing that could ruin the social environment inside a space ship is some bastard jerking off without using the vacuum device.
I am sure this is a thing that probably is covered somewhere on astronaut's operational handbooks.
Oh noes! A SUV fanatic!
Err... don't take offense, but viagra is a lot cheaper.
I, for one, welcome our African-AIDS-immune overlords.