November 16, 2009 at 12:20 pm
Comments posted to this topic are about the item Surely It Should Just Work?
Best wishes,
Phil Factor
November 16, 2009 at 12:56 pm
Of course it "should just work", but so should everything else.
My car has an automatic transmission. My wife's has a manual. If I try to drive hers the way I drive mine, I'll destroy the engine by staying in first gear the whole trip. If I try to drive mine the way I drive hers, I'll be pounding on the left side of the brake pedal and messing stuff up every time I try to change gears and there isn't a clutch pedal there.
She has a Swiss Army knife, I have a locking-blade pocket knife. Again, try to use them the same way, and I'm liable to lose fingers (hers doesn't lock), or break the knife (mine doesn't have a bottle opener or screwdriver on it).
Shouldn't those things "just work"? Yep. But they don't. You have to use a tool the way it's designed. Some are going to be optimized for one thing, some for others.
I can do things with my knife, because of the locking blade, that wouldn't be safe with hers. I can do things with hers that wouldn't be possible with mine.
Surely pocket knives, perhaps the most ancient piece of technology on the planet, should be similar enough that specialized expertise with one would translate into specialized expertise with the other. Or they should "just work" well enough that one doesn't need specialized expertise with any knife. If you think that, then try doing with a fileting knife what you would do with a chisel, or vice versa.
So, why should software, which is just another tool, have some special "just workness" to it, that no other technology on this planet has? Specialization by tools and knowledge has always been humanity's greatest evolutionary advantage. Why would that have changed in the last 50 years? Different tools should have different strengths and weaknesses. Over time, these will evolve into the kind of true specializations that differentiate a jewler's mallet from a hydraulic press (both are hammers).
Sure, the differences now aren't that well-defined and don't have that kind of special utility, in some cases. But we are seeing some of it, a la, SQL Mobile vs SQL Enterprise. It just takes some time to really get there. Wheelbarrows vs 18-wheelers didn't happen in a decade or five.
- Gus "GSquared", RSVP, OODA, MAP, NMVP, FAQ, SAT, SQL, DNA, RNA, UOI, IOU, AM, PM, AD, BC, BCE, USA, UN, CF, ROFL, LOL, ETC
Property of The Thread
"Nobody knows the age of the human race, but everyone agrees it's old enough to know better." - Anon
November 16, 2009 at 1:51 pm
That was an amazing analogy G.. It is just perfect..
CEWII
November 16, 2009 at 1:59 pm
Elliott W (11/16/2009)
That was an amazing analogy G.. It is just perfect..CEWII
Thanks.
I view things from an evolutionary viewpoint, and that includes tools and ideas.
- Gus "GSquared", RSVP, OODA, MAP, NMVP, FAQ, SAT, SQL, DNA, RNA, UOI, IOU, AM, PM, AD, BC, BCE, USA, UN, CF, ROFL, LOL, ETC
Property of The Thread
"Nobody knows the age of the human race, but everyone agrees it's old enough to know better." - Anon
November 16, 2009 at 2:02 pm
The part I like the best is that it paints a VERY clear picture and the comparison is VERY apples to apples.
CEWII
November 17, 2009 at 6:43 am
I don't know how many times I've seen people use functions (especially user-defined functions) as if they were overhead free. After all, the form "function(parameter)" looks so simple, but could easily be hiding enormous amounts of machine time (and calling other UDFs that hide more machine time). Unless users really think about what they are doing in terms of cpu and disk access, it's easy to be lulled into poor design.
Even with sophisticated optimizers, user constructs can (if the user does not understand them) prevent the use of optimization.
[at the extreme, we might consider the mathematician's "function" which is often an abstract to clean up a proof. The fact that such a 'function' could take longer than the age of the universe to execute is immaterial the mathematicians.]
...
-- FORTRAN manual for Xerox Computers --
November 17, 2009 at 6:50 am
GSquared (11/16/2009)
She has a Swiss Army knife, I have a locking-blade pocket knife.
I think it's cool both you and your wife have knives 🙂
November 17, 2009 at 6:53 am
Steve Jones - Editor (11/17/2009)
GSquared (11/16/2009)
She has a Swiss Army knife, I have a locking-blade pocket knife.I think it's cool both you and your wife have knives 🙂
It's mankind's oldest invention (as opposed to the rock or club, which is the oldest discovery), and still useful on a day-to-day basis. I don't understand why anyone would not carry one.
- Gus "GSquared", RSVP, OODA, MAP, NMVP, FAQ, SAT, SQL, DNA, RNA, UOI, IOU, AM, PM, AD, BC, BCE, USA, UN, CF, ROFL, LOL, ETC
Property of The Thread
"Nobody knows the age of the human race, but everyone agrees it's old enough to know better." - Anon
November 17, 2009 at 8:00 am
Steve Jones - Editor (11/17/2009)
GSquared (11/16/2009)
She has a Swiss Army knife, I have a locking-blade pocket knife.I think it's cool both you and your wife have knives 🙂
And clearly his wife has the smarts in the family! Swiss Army Knives can be AMAZINGLY useful tools! I have been carrying one (except on commercial flights - dammit!!) for almost 30 years. Being able to travel with my knife is one of the hidden benefits to having my own plane! 😎
As for the article and thought that databases should just work, I say poppy-cock, and not just because the original premise comes from Joe Celko. ANY reasonably complex system where you want/need optimal performance or to be able to capture every little nook-and-cranny feature REQUIRES one (or at least part of the group) to be WELL VERSED in the internals of said system.
Best,
Kevin G. Boles
SQL Server Consultant
SQL MVP 2007-2012
TheSQLGuru on googles mail service
November 17, 2009 at 8:05 am
It is fair to say who wouldn’t want it “To Just Work”. But at what cost? If all products just worked what would be the differentiators between one product and another.
There are good reasons to work towards standards so there is a degree of interoperability but in reality how good is that interoperability.
What standards and commonality does do is gives the developers a common ground to communicate and learn. Products should continue to evolve and “Just work” better. But not at the cost of providing real improvements and benefits to functionality and performance.
Many years ago I worked on a project that used the Java Message Queue stuff. Functionally it just worked. But the reference implementation was not robust enough for an enterprise environment. In comes a 3rd party product that cost $6K per processor but had a ridiculous performance and scalability compared to the reference implementation. Yes to Phil’s point it did just work, which is good, but the different implementations had different optimizations. If they were exactly the same where is the differentiator that make one more valuable than the other. If they are different then they will have different ways to use them that can impact the developer.
November 17, 2009 at 12:01 pm
Whatever the main premise of your article, you mentioned a "very simple four-way join" that "took ten times as long" in PostgreSQL as it did in SQL Server. I have been trying to get my Microsoft-worshipping supervisor to more seriously consider open source, and have been recommending PostgreSQL over MySQL based on its more mature capabilities and fewer potential licensing problems. So you can understand that I really want to know more details about such a shocking statement as you have made. Please elaborate.
November 17, 2009 at 12:35 pm
bpatin (11/17/2009)
Whatever the main premise of your article, you mentioned a "very simple four-way join" that "took ten times as long" in PostgreSQL as it did in SQL Server. I have been trying to get my Microsoft-worshipping supervisor to more seriously consider open source, and have been recommending PostgreSQL over MySQL based on its more mature capabilities and fewer potential licensing problems. So you can understand that I really want to know more details about such a shocking statement as you have made. Please elaborate.
I would like to hear you elaborate on why you are pushing those other RDBMS platforms...
Best,
Kevin G. Boles
SQL Server Consultant
SQL MVP 2007-2012
TheSQLGuru on googles mail service
November 17, 2009 at 12:41 pm
bpatin (11/17/2009)
have been recommending PostgreSQL over MySQL
bpatin: did you mean PostgreSQL over SQL? I agree PostgreSQL has more mature capbilities than MySQL, but licensing issues?
As far as this topic goes, I think the onus is on the developer to understand the difference in database applications and platforms to achieve the best performance in his/her application. It is the developer's responsibility to understand the technology they are manipulating. Luckily the basic principles of databases apply to most and they are not going to have to start from scratch, but they will need to find out the differences and learn how to best utilize the technology at hand.
just my .02
November 17, 2009 at 12:48 pm
...I really want to know more details about such a shocking statement as you have made. Please elaborate.
I rate PostgreSQL quite highly, and my friends who use it say it is greatly improved now. I don't think that it is a shocking statement to say that a simple four-way join took ten times longer, though. It just underlines how careful one has to be with porting a database from one platform to another.
Until recently I had the offending execution plan, but I can't put my hands on it. I was writing the database for a J2E/postreSQL application. Just because the development tools were better in SQL Server, I wrote the first cut in SQL Server, and stocked it with realistic data. I ran test timings on all the SQL Calls. I then ported the database to PostgreSQL (it was surprisingly simple) using the EMS PostgreSQL tools. I then ran the same timings. The PostgreSQL database was hosted on Linux (I also tried the Windows version with similar results) on hardware that was pretty-well identical to the SQL Server version. The purpose of the timings was to check that the indexing I'd used for SQL Server was appropriate for PostgreSQL, and to flag up any problems. The problem with the four-way joins was somewhat embarrassing as I'd had an argument with the Devs over denormalization. I'd demonstrated, using SQL Server, that there was no measurable difference on SQL Server between a fully-normalized NAD subsystem that involved a four-way join and a denormalized two-way join. I was not happy to find out that the same wasn't true with PostgreSQL. I put the offending query and plan on some PostgreSQL sites and asked PostgreSQL experts, and did everything they suggested, but I never got the speed up to SQL Server. If I remember right, the problem was due to the postgreSQL indexes not 'covering' the query in the same way as SQL Server.
PostgreSQL deserves our support as being the only free open source relational database that is community-owned and published under a BSD Licence. I'm happy to recommend it where the use of SQL Server is not appropriate for some reason, but it is unfair on PostgreSQL to compare it directly with an industrial-strength commercial database such a SQL Server; it is hardly surprising to find that there are occasions where it doesn't match up. It has improved enormously in the time since I used it.
Best wishes,
Phil Factor
November 18, 2009 at 12:29 am
...but one can harbour a sneaking sympathy for the harassed application developer who has, perforce, become an 'Accidental DBA'...
Thank you for that sympathy! 🙂 In a similar manner I would have sympathy on a DBA who had to start programming.
Viewing 15 posts - 1 through 15 (of 30 total)
You must be logged in to reply to this topic. Login to reply