Re: WWW/Internet 2009: 2nd CFP until 21 September x
Date: Sun, 16 Aug 2009 01:32:34 GMT
Bob Badour wrote:
> paul c wrote: >
>> Walter Mitty wrote:
>>> The way I think of it is that every table with nulls in it is a
>>> materialized outer join. If you can decompose the table into
>>> multiple tables each of which has no nulls, what you discover is that
>>> a null in the combined table corresponds to an absent row in one of
>>> the decomposed tables.
>>> Let me shift gears back into practical mode for a minute. In any
>>> database I've ever worked with, the majority of columns are not a
>>> primary key, or a foreign key or a part of a primary or foreign key,
>>> or ever appear in a where of having clause.
> > But they often appear in aggregates, which makes my earlier example > particularly grave: > > SUM(A)+SUM(B) doesn't always equal SUM(A)+SUM(B) let alone SUM(A+B) > ...
Here's some mea culpa. As bizarre as it sounds, I was once hired to implement nulls in an non-sql product because a big bank insisted on it, claimed their particular null was essential for runs of cheques that all bounced. I took the job just because it sounded less humdrum than what I'd been doing, trying to bend obscure products like model204. Later, I contracted for customers who wanted to record various things for which not all details were always available. Can't remember every case, but I remember convincing a number of customers to twist their requirements so that labels could be empty strings and zero was valid for various quantities. But I never did figure how how to default dates without changing app code.
If I knew then what I know now (and if I'd had any guts/courage of my convictions), I would have refused the whole business and gone into a sensible line of work. Or I could just blame it all on the assembler programmer mentality/brainwashing that accepts the dumbest ideas as a challenge. At one time, maybe it was when Dijkstra was active and 'The Psychology of Computer Programming' was a current book, this culture was evident amond C programmers. I would have thought then that future languages might help eliminate the phenomenon, but now it looks like I was wrong. Maybe it's because they aren't really that different and the newer programming environments/frameworks aren't very imaginative after all.
In a way I'm as fanatical about this as reformed smokers are about the effects of nicotine, carbon monoxide and formaldehyde on the interiors of their ignition-spark powered cars. Its harder to just say no when you're staring at big bucks and products offer so much less automation than tthey could. I have some sympathy for Walt's comments on the grounds that I thought more than half of the apps I saw wouldn't have been needed in those businesses if I had been signing the cheques, let alone most of the requirements. Never saw one that eliminated people, just shifted them. Not saying there aren't any, but there aren't many. There are a few apps without which a business isn't possible. Long before amazon.com, the airlines knew this. Today, there is a huge number of single-user apps which people find tremendously useful. Some of the vaunted mass business efficiency systems are quite screwed up, for example two litres of milk at the local Walmart costs a buck more than at the local premium price Safeway stores. The Walmart milk comes from local dairies and the Safeway milk comes from another province on the other side of the mountains!
In those days I had only the vaguest knowledge of relational ideas, used to talk to customers about what I called uniform sentences. Once or twice I was able to convince them to drop various requirements on the grounds they were artificial or didn't affect the bottom line and that those systems would cost more to build, run and maintain. But I never convinced the IT people, I always had to go over their heads. Most of the time that didn't work either, but it created lots of powerful enemies in the big international consulting companies who had dedicated handlers for all their accounts.
As Luddite as all this may sound, I think there is a larger proportion of people in IT than in most other of the mundane fields who are deficient in their chosen field, at least in the sense that their irresponsibility usually has a more lasting effect. Of course there are very few faithful travellers in any field and I've met more incompetent doctors, lawyers and especially dentists, than competent ones, but at least they didn't try to throw bumpf theory at me, it was mutually understand they were in it for the money or some kind of prestige. For one thing, people in those lines understand how easily they can be sued.
Database theory is far from being the most pressing issue in human affairs and the forces at play in the really pressing ones are much more complicated. One would think in such a relatively small and insignificant (to most people) area it shouldn't be as hard to get it right as history seems to show. Received on Sat Aug 15 2009 - 20:32:34 CDT