Re: Generalised approach to storing address details
From: paul c <toledobythesea_at_oohay.ac>
Date: Wed, 13 Dec 2006 01:09:30 GMT
Message-ID: <epIfh.477115$R63.85324_at_pd7urf1no>
>> Cimode wrote:
>>
>>> RM was created on the first place in the perspective of getting away
>>> from the sterile hierarchic paradigm of computing...A way for breaking
>>> the vicious circle in which lots of idiots try to get us back...
>>>
>>
>>
>> Entirely false and self-serving.
>>
>> First, RM was created in "reaction to the escalating costs required for
>> deploying and maintaining complex systems". It had nothing to do with
>> 'getting away from the sterile hierarchic paradigm of computing' and
>> everything to do with providing a logical, declarative data model which
>> would allow "programmers to describe the information they wanted and
>> to leave the details of optimization and access to the database
>> management system". [Double quoted text from:
>>
>> http://www.acmqueue.com/modules.php?name=Content&pa=showpage&pid=299
>>
>> ]
>>
>> Second, 'sterile hierarchic paradigm of computing' is your opinion,
>> nothing more. In point of fact, everything the average computer
>> enduser/knowledgeworker uses (besides spreadsheets and SQL responses)
>> is hierarchical: menus, org charts, table of contents, the Web.
>> Sterile for you perhaps, but effective for the rest of us.
>>
>> If one objective of database experts is to broaden access to
>> databases and use of relational technologies, perhaps the experts
>> should show some concern for making such access and use available
>> through interfaces (like hierarchical) that are more intuitive
>> to non-experts instead of branding as 'idiots' anyone who cannot
>> master modeling with relations, formulating queries in SQL or
>> making sense of unnormalized SQL extensions (i.e., query
>> responses).
>>
>> Your vitriol sounds to me like job security: As long as the gcd
>> (greatest common denominator) interface to RDBs and RDBMEs (engines,
>> servers) remains SQL, you will be in great demand. Considering that
>> a small business could deploy a competent RDBMS for less than $5K
>> and the annual cost of one SQL expert is upwards of $250K, one has
>> to regard the SQL Meta Meta Model as the most significant obstacle
>> to the widespread DIRECT use of database technology by those who
>> are not SQL experts.
>>
>> Rob
>>
Date: Wed, 13 Dec 2006 01:09:30 GMT
Message-ID: <epIfh.477115$R63.85324_at_pd7urf1no>
paul c wrote:
> Rob wrote: >
>> Cimode wrote:
>>
>>> RM was created on the first place in the perspective of getting away
>>> from the sterile hierarchic paradigm of computing...A way for breaking
>>> the vicious circle in which lots of idiots try to get us back...
>>>
>>
>>
>> Entirely false and self-serving.
>>
>> First, RM was created in "reaction to the escalating costs required for
>> deploying and maintaining complex systems". It had nothing to do with
>> 'getting away from the sterile hierarchic paradigm of computing' and
>> everything to do with providing a logical, declarative data model which
>> would allow "programmers to describe the information they wanted and
>> to leave the details of optimization and access to the database
>> management system". [Double quoted text from:
>>
>> http://www.acmqueue.com/modules.php?name=Content&pa=showpage&pid=299
>>
>> ]
>>
>> Second, 'sterile hierarchic paradigm of computing' is your opinion,
>> nothing more. In point of fact, everything the average computer
>> enduser/knowledgeworker uses (besides spreadsheets and SQL responses)
>> is hierarchical: menus, org charts, table of contents, the Web.
>> Sterile for you perhaps, but effective for the rest of us.
>>
>> If one objective of database experts is to broaden access to
>> databases and use of relational technologies, perhaps the experts
>> should show some concern for making such access and use available
>> through interfaces (like hierarchical) that are more intuitive
>> to non-experts instead of branding as 'idiots' anyone who cannot
>> master modeling with relations, formulating queries in SQL or
>> making sense of unnormalized SQL extensions (i.e., query
>> responses).
>>
>> Your vitriol sounds to me like job security: As long as the gcd
>> (greatest common denominator) interface to RDBs and RDBMEs (engines,
>> servers) remains SQL, you will be in great demand. Considering that
>> a small business could deploy a competent RDBMS for less than $5K
>> and the annual cost of one SQL expert is upwards of $250K, one has
>> to regard the SQL Meta Meta Model as the most significant obstacle
>> to the widespread DIRECT use of database technology by those who
>> are not SQL experts.
>>
>> Rob
>>
> > Don't believe everything you read. The above and the link make it sound > as if a famous corporate body could predict the future, which wasn't > true thirty-five years ago and isn't now! It's usually a rare > individual who happens to do that, usually without knowing it. > > In 1969, an average programmer's salary was somewhere between 2% and 5% > of a small IBM mainframe nominal purchase price (often, they could only > be leased or rented) and an even smaller portion of a large one. That > doesn't count maintenance and peripherals which could multiple the > hardward cost. > > Look for some other sources. It shouldn't be hard to see that Codd's > early effort was not part of a concerted research effort and it > shouldn't be hard to see that one of his big interests was to show what > adhoc, illogical quicksand the typical, physically-oriented database > efforts of the day were built on, such as IBM's IMS and Vandl and all > the Cincom and IDS stuff. It wasn't so much cost that Codd was > interested in but rather dispelling some of the nonsense. In many > endeavours, dispelling nonsense can reduce costs. Obviously savings > would arise from one of his main points, the idea of sharing data rather > than replicating it as those "DB" products did, but the fact was that at > that time, the bulk of commercial data was not even maintained by > so-called dbms'es, rather file-based applications. > > p
Further, in those days, the emerging problem wasn't cost of changes, but timeliness and unwieldiness of changes. It was often called the "maintenance problem". It was not unusual for a non-DP-wise director in a meeting about a computer system problem to ask "is this a problem that can be solved with money"!
p Received on Wed Dec 13 2006 - 02:09:30 CET