- - - - - Tables have "indexes". If you use a SELECT statement with a search request for which there is no helpful index, the entire table will be linearly searched. This is slow. - - - - -
Some tables have indexes. Some don't. Sometimes it is faster to access rows via an index, and sometimes a full table scan is faster (and in the cases where a full table scan is faster, it will typically be 100x faster than index-to-table access).
I agree with you that getting started is not that hard (you can also download Oracle for free for training purposes as well), and that doing things from an early stage is key. However, a good solid understanding of the fundamentals is critical and it is not anywhere near as simple as your post would indicate. Very few powerful tools are simple, once you get past the "neat-o!" stage.
I'm not sure it is possible, today. From about 1995-2005 forward a large amount of database work, and development of applications against databases, was done by people who didn't really have a good grasp of the fundamentals of the concept, the history of its implementation, or a very thorough knowledge of the available technology. The result is that various self-taught paradigms became embedded in an entire generation of developers, and those paradigms have now been picked up and embedded in technology by vendors. As a result it is very difficult to get any training or mentoring, or even find any books published after 1995, that go through the fundamentals and provide solid examples of the various paradigms and patterns and the strengths/weaknesses of each. IMHO that's in large part because the older patterns were stronger but more difficult to understand and use, so they got pushed aside by the self-taught patterns which are now dominate.
As a related example see this thread - I would personally say that Postgres and Oracle RDBMS each have their strengths and weaknesses, and each have places where they should be used and should not be used, but the rabid anti-Oracle posters dominate the discussion and shout down any reasoned discussion. Similarly with the "business logic in the RDBMS" paradigm - in my experience over 25 years that often works far better than the "tons of Java middleware" approach, but while each has its advantages the proponents of the latter generally shout down the former. So you only get one viewpoint, and that not always the strongest (again IMHO).
The state of business software development trends leaves me a big depressed, actually.
Date is of course very good in the earlier editions if you can understand his math. Later on he went down his own non-traditional path that is more than a bit off the mainstream, and of course there are many very capable database people who don't use or claim to be experts at relational calculus or symbolic logic (was a bit shocked to find out Tom Kyte was in that camp, although he interacts quite a bit with Cary Milsap who is on the other extreme). Kyte's books are very good although practical and not theory, and of course 99% Oracle. _Tales of the Oak Table_ is a good read with many cautionary tales and although written by Oracle professionals the case studies apply to any information technology.
Impossible! North Carolina and Arizona, at least, are libertarian paradises - very "business friendly" - that would _never_ pass legislation interfering with markets or freedom to contract. Never! There must be some misunderstanding.
- - - - - I understand that not all customers can do this, however.
Whereas my experience is more with a bewildered business unit representative being handing a 200 page "spec" in dense type and bizarre, technical language and told he has until Thursday to approve it (with all the time invested, it is understood that no spec can ever be rejected); then being equally bewildered when the mods delivered (which do in fact match the spec, modulo interpretation) don't do anything like what he needs them to do or thinks he asked for. Similarly with dozens of business unit reps sitting in a room reading laboriously through aforementioned spec line by line and being told to "sign off" on each page; when it doesn't work they are contemptously asked 'why didn't you speak up in the review meeting?'.
sPh
Re:Are you nuts? Don't talk agile with the custome
on
Why Your Users Hate Agile
·
· Score: 5, Interesting
If anyone thinks that there is complete, 100%, nailed down design for a 75-story skyscraper before any digging starts, and that the design for the 69th floor is similarly nailed down before the 3rd floor is finished, they need to spend some time on a construction site. The overall shape of the building, the structural design, the very bottom and top floors, and the allowable parameters for design of the later floors, sure. But the exact design of floors 50-72? No. Plan for what happens when the selected elevator supplier goes bankrupt, the ship carrying a key delivery of structural steel sinks, the developer finally signs a tenant for 68-70 and he wants an internal staircase and private elevator for his offices? No. Look up "fast-track" in a construction dictionary.
The context here is large-scale software and/or systems development, not mechanical/civil engineering. The latter are different animals due to (a) an additional 200 years of experience in discarding what doesn't work (b) the ability to overdesign to avoid unk unks (that's what "factor of safety" means, a concept that James Eads learned the hard way from his mentor) (c) the existence of reasonably clear scientific laws that drive the design. Maybe in 2140 software design and development will have reached an equivalent state of capability, but it isn't clear that there are any scientific principles equivalent to the laws of mechanics that apply.
- - - - - Agile/Extreme programming is the alternative medicine of software development. It's a collection of mostly unrelated and sometimes contradictory concepts, the only common thing between them being lack of widespread adoption. Like alternative medicine, it has components that are useful in some circumstances. These give unearned credibility to Agile, even though they were there well before it. The problem is also similar, these components are taken to the extreme and are claimed to be universal solutions to every situation. - - - - -
I actually don't disagree, but I would think honesty would compel one to note that one could replace the word "Agile" in that paragraph with the name of any of the structured, "rigorous" methodologies and the observation would be equally valid. Unless one has unlimited time and budget, and the architectural equivalent of demigods, the structured methodologies fail very often too.
I've seen waterfall projects fail. The answer was always 'We didn't follow our processes rigorously enough.' No. waterfall can be as foolish a project management method as any other but it seems to have a religious component to it. There were always some change resistors who needed to be sent for more PMBOK training or just rooted out. Probably they were casting magic anti-ISO spells or something.
IIRC the UK government's last attempt to build a big national data processing system using the waterfall methodology ended up after 5 years in no system and a 5x10e9 GBP lawsuit against one of the world's largest consultancies. Does that mean that advocates of waterfall claim they "shit unicorns and daisies" and their methodology "can't be failed"?
Having bashed waterfall quite a bit upthread, I will say that I have no desire to have Facebook's developers program my bank account or inventory control system. Sometimes consistent, validated transactions that don't randomly disappear really are important.
- - - - - Agreed. Agile is a WHOLE lot easier to get wrong than it is to get right. - - - - -
Of course waterfall and other strict-spec methodologies have a 72 year history [1] of failing spectacularly too, and from about 1980 have had the added bonus of being too slow for business velocity.
sPh
[1] counting from about 1940, although projects using the mechanical accounting systems of the 1920s may have had similar problems
- - - - - A developer's job, in a project like that, isn't to come up with something good. Their job is to implement a specific piece of functionality in the specific way defined by the people whose job is to have the broader view of the project. - - - - -
The unstated assumption in that theory is that there is a group of human beings who are unto demigods, capable of defining detailed specifications that cover all eventualities, see far into the future, and can be implement mechanistically by simple code grinders. I have run into two or three such people in my entire career, out of the thousands of system architects and business analysts I have worked with in some capacity. And even those three people (a) often got caught by surprise by unintended side-effects (b) were often part of a process that took so long to come to fruition the system so designed was obsolete by the time it was deployed.
The only industry I am aware of where strict, spec-controlled waterfall is probably appropriate and generally works is aerospace controls systems. Of course that industry is notorious for huge schedule and cost overruns (the A400 software fiasco is particularly instructive in this regard), and even their software is not free from bugs and unintended consequences. Ref the numerous changes Boeing has made to the electrical system control software on the B-787 since it went into service - why didn't they just "get the spec right the first time"? Enrico Fermi's comment on how to manage the unknown is very instructive.
Assuming the parent is (1) not kidding (2) referring to wool socks, it is quite possible. Wool clothing was far better made 25 years ago than it is today, and far more durable than almost anything on the apparel market now. Not all change is "progress".
- - - - - If you choose small Italian cars as your unit of currency, they can always be driven, (providing value) no matter how much you've devalued them. - - - - -
You must have a special source of small Italian cars that aren't in the repair shop 360 days of the year.
= = = but why would someone spot their company 125k of cash on a credit card? = = =
For any corporate account small that GiganticCo, when you as an employee accept an Amex corporate card it has your name on it and you agree to be liable to Amex for all charges on the card, whether or not your employer pays through their direct-bill account. If the employee was direct to use his "corporate account" card as a p-card to pay for a major purchase, and his employer then failed to pay the invoice, well, he'd be in a heap-o-trouble.
= = = No, it's one of the dumbest ideas I've seen spread across the Internet lately. = = =
Interesting, since is a theme that occurs quite regularly in the work of Poul Anderson, one of the original SF libertarian tough guys. Anderson, writing in the 1950s, put the arrival of a post-scarcity society around 2100, but in many respects the developed world is there today [1]: full output can be sustained with a fraction of the population well below 1.00.
[1] Modulo the availability of petroleum of course
Yes, the various economic actors worked auto-magically in concert to clean up the Great Lakes in the early 1970s based on nothing except price signals!
Very, very few at the K-12 level (and not all that many at the college level either). And even where the concept of "tenure" exists in K-12, it is nothing like top-rank university tenure; teachers can be and are fired for all sorts of reasons not involving their performance (e.g. annoying a key school board member with their political views) tenure or no.
- - - - - It turns out, there's a special "extended range" mode that will put the battery at 100% instead of 90%. It reduces battery life.
Most normal people would consider "charging complete" to mean, you know, charging complete. - - - - -
Agreed. The idea that drivers will spend their time deciding what "mode" their vehicle is currently operating in, particularly when that mode is (a) invisible to the driver (b) reportedly reduces life of the key vehicle component, isn't a very good advertisement for all-electric vehicles.
sPh
I personally think that to the extent we still have personally driven automotive vehicles in 2032 they will look like today's Chevy Volt, except with a small diesel instead of gas. Pure electric isn't going to make it for many reasons, but auxiliary load (especially HVAC) is the big one.
Slashdot Mirror
Brilliant! Why haven't the grid operators thought of that one?!?
sPh
Of course, large power transformers can be damaged by electromagnetic storms even when fully disconnected from the grid...
Well, if you lived in Quebec or worked for any of the Canadian electric transmission providers your viewpoint might be a bit different...
sPh
Some tables have indexes. Some don't. Sometimes it is faster to access rows via an index, and sometimes a full table scan is faster (and in the cases where a full table scan is faster, it will typically be 100x faster than index-to-table access).
I agree with you that getting started is not that hard (you can also download Oracle for free for training purposes as well), and that doing things from an early stage is key. However, a good solid understanding of the fundamentals is critical and it is not anywhere near as simple as your post would indicate. Very few powerful tools are simple, once you get past the "neat-o!" stage.
sPh
I'm not sure it is possible, today. From about 1995-2005 forward a large amount of database work, and development of applications against databases, was done by people who didn't really have a good grasp of the fundamentals of the concept, the history of its implementation, or a very thorough knowledge of the available technology. The result is that various self-taught paradigms became embedded in an entire generation of developers, and those paradigms have now been picked up and embedded in technology by vendors. As a result it is very difficult to get any training or mentoring, or even find any books published after 1995, that go through the fundamentals and provide solid examples of the various paradigms and patterns and the strengths/weaknesses of each. IMHO that's in large part because the older patterns were stronger but more difficult to understand and use, so they got pushed aside by the self-taught patterns which are now dominate.
As a related example see this thread - I would personally say that Postgres and Oracle RDBMS each have their strengths and weaknesses, and each have places where they should be used and should not be used, but the rabid anti-Oracle posters dominate the discussion and shout down any reasoned discussion. Similarly with the "business logic in the RDBMS" paradigm - in my experience over 25 years that often works far better than the "tons of Java middleware" approach, but while each has its advantages the proponents of the latter generally shout down the former. So you only get one viewpoint, and that not always the strongest (again IMHO).
The state of business software development trends leaves me a big depressed, actually.
Date is of course very good in the earlier editions if you can understand his math. Later on he went down his own non-traditional path that is more than a bit off the mainstream, and of course there are many very capable database people who don't use or claim to be experts at relational calculus or symbolic logic (was a bit shocked to find out Tom Kyte was in that camp, although he interacts quite a bit with Cary Milsap who is on the other extreme). Kyte's books are very good although practical and not theory, and of course 99% Oracle. _Tales of the Oak Table_ is a good read with many cautionary tales and although written by Oracle professionals the case studies apply to any information technology.
sPh
But how do you write the big spec for that? The PMI would never approve.
sPh
Impossible! North Carolina and Arizona, at least, are libertarian paradises - very "business friendly" - that would _never_ pass legislation interfering with markets or freedom to contract. Never! There must be some misunderstanding.
sPh
Whereas my experience is more with a bewildered business unit representative being handing a 200 page "spec" in dense type and bizarre, technical language and told he has until Thursday to approve it (with all the time invested, it is understood that no spec can ever be rejected); then being equally bewildered when the mods delivered (which do in fact match the spec, modulo interpretation) don't do anything like what he needs them to do or thinks he asked for. Similarly with dozens of business unit reps sitting in a room reading laboriously through aforementioned spec line by line and being told to "sign off" on each page; when it doesn't work they are contemptously asked 'why didn't you speak up in the review meeting?'.
sPh
If anyone thinks that there is complete, 100%, nailed down design for a 75-story skyscraper before any digging starts, and that the design for the 69th floor is similarly nailed down before the 3rd floor is finished, they need to spend some time on a construction site. The overall shape of the building, the structural design, the very bottom and top floors, and the allowable parameters for design of the later floors, sure. But the exact design of floors 50-72? No. Plan for what happens when the selected elevator supplier goes bankrupt, the ship carrying a key delivery of structural steel sinks, the developer finally signs a tenant for 68-70 and he wants an internal staircase and private elevator for his offices? No. Look up "fast-track" in a construction dictionary.
sPh
The context here is large-scale software and/or systems development, not mechanical/civil engineering. The latter are different animals due to (a) an additional 200 years of experience in discarding what doesn't work (b) the ability to overdesign to avoid unk unks (that's what "factor of safety" means, a concept that James Eads learned the hard way from his mentor) (c) the existence of reasonably clear scientific laws that drive the design. Maybe in 2140 software design and development will have reached an equivalent state of capability, but it isn't clear that there are any scientific principles equivalent to the laws of mechanics that apply.
sPh
Wall Street called; they need another trillion $ of bailout money. Unmarked 20s straight from the taxpayers' pockets please.
Superfund is another example that comes to mind.
sPh
I actually don't disagree, but I would think honesty would compel one to note that one could replace the word "Agile" in that paragraph with the name of any of the structured, "rigorous" methodologies and the observation would be equally valid. Unless one has unlimited time and budget, and the architectural equivalent of demigods, the structured methodologies fail very often too.
sPh
I've seen waterfall projects fail. The answer was always 'We didn't follow our processes rigorously enough.' No. waterfall can be as foolish a project management method as any other but it seems to have a religious component to it. There were always some change resistors who needed to be sent for more PMBOK training or just rooted out. Probably they were casting magic anti-ISO spells or something.
IIRC the UK government's last attempt to build a big national data processing system using the waterfall methodology ended up after 5 years in no system and a 5x10e9 GBP lawsuit against one of the world's largest consultancies. Does that mean that advocates of waterfall claim they "shit unicorns and daisies" and their methodology "can't be failed"?
sPh
That's actually not a bad idea/observation - if you have some deeper thought behind that you could probably get at least a book out of it.
sPh
Having bashed waterfall quite a bit upthread, I will say that I have no desire to have Facebook's developers program my bank account or inventory control system. Sometimes consistent, validated transactions that don't randomly disappear really are important.
sPh
Of course waterfall and other strict-spec methodologies have a 72 year history [1] of failing spectacularly too, and from about 1980 have had the added bonus of being too slow for business velocity.
sPh
[1] counting from about 1940, although projects using the mechanical accounting systems of the 1920s may have had similar problems
The unstated assumption in that theory is that there is a group of human beings who are unto demigods, capable of defining detailed specifications that cover all eventualities, see far into the future, and can be implement mechanistically by simple code grinders. I have run into two or three such people in my entire career, out of the thousands of system architects and business analysts I have worked with in some capacity. And even those three people (a) often got caught by surprise by unintended side-effects (b) were often part of a process that took so long to come to fruition the system so designed was obsolete by the time it was deployed.
The only industry I am aware of where strict, spec-controlled waterfall is probably appropriate and generally works is aerospace controls systems. Of course that industry is notorious for huge schedule and cost overruns (the A400 software fiasco is particularly instructive in this regard), and even their software is not free from bugs and unintended consequences. Ref the numerous changes Boeing has made to the electrical system control software on the B-787 since it went into service - why didn't they just "get the spec right the first time"? Enrico Fermi's comment on how to manage the unknown is very instructive.
sPh
I was too busy reading the RFC drafts via Gopher to bother with "formatting".
sPh
Assuming the parent is (1) not kidding (2) referring to wool socks, it is quite possible. Wool clothing was far better made 25 years ago than it is today, and far more durable than almost anything on the apparel market now. Not all change is "progress".
sPh
You must have a special source of small Italian cars that aren't in the repair shop 360 days of the year.
sPh
For any corporate account small that GiganticCo, when you as an employee accept an Amex corporate card it has your name on it and you agree to be liable to Amex for all charges on the card, whether or not your employer pays through their direct-bill account. If the employee was direct to use his "corporate account" card as a p-card to pay for a major purchase, and his employer then failed to pay the invoice, well, he'd be in a heap-o-trouble.
sPh
Interesting, since is a theme that occurs quite regularly in the work of Poul Anderson, one of the original SF libertarian tough guys. Anderson, writing in the 1950s, put the arrival of a post-scarcity society around 2100, but in many respects the developed world is there today [1]: full output can be sustained with a fraction of the population well below 1.00.
[1] Modulo the availability of petroleum of course
Yes, the various economic actors worked auto-magically in concert to clean up the Great Lakes in the early 1970s based on nothing except price signals!
Oh wait...
sPh
Very, very few at the K-12 level (and not all that many at the college level either). And even where the concept of "tenure" exists in K-12, it is nothing like top-rank university tenure; teachers can be and are fired for all sorts of reasons not involving their performance (e.g. annoying a key school board member with their political views) tenure or no.
sPh
Agreed. The idea that drivers will spend their time deciding what "mode" their vehicle is currently operating in, particularly when that mode is (a) invisible to the driver (b) reportedly reduces life of the key vehicle component, isn't a very good advertisement for all-electric vehicles.
sPh
I personally think that to the extent we still have personally driven automotive vehicles in 2032 they will look like today's Chevy Volt, except with a small diesel instead of gas. Pure electric isn't going to make it for many reasons, but auxiliary load (especially HVAC) is the big one.