Re: pro- foreign key propaganda?

paul c <toledobysea_at_ac.ooyah> writes:
> In the 1970 mainframe culture that Codd was trapped in, 'key' had an
> extremely physical connotation, in fact some hardware supported 'keys'
> directly with dedicated machine-level operators. Many practitioners
> had grown up depending on file-level keys, as for IMS, its various
> keys were all encumbered with various navigational meanings. I think
> Codd was just as much a pragmatist as a theorist and even though his
> keys weren't at all the same thing he might have used continued the
> term to ease his 'sales pitch'. If he had called them, say, the
> inference set', he might have expected even more resistance than he
> did from the ignorants of the day. While academics embraced his ideas
> quickly, he suffered many personal attacks from the powerful
> marketeers at a time when IBM was maybe more dominant than microsoft
> is today. Ironic, because IMS was used as way to help sell then big
> IO-oriented slow-cpu iron and the implementations that followed Codd
> were attacked for supposedly needing more hardware than IMS did. I
> remember an Amdahl salesman saying, "give me more of this relational
> stuff, I'll sell more cpu's!".

i've commented before that the 60s era databases had direct pointers exposed as part of the record.

also the underlying disk technology had made a trade-off between relatively abundant i/o capability and the limited availability of real/electronic storage in the "CKD" ... count-key-data architecture ... misc. past posts
http://www.garlic.com/~lynn/subtopic.html#dasd

... it was possible to create i/o requests that performed extended searches for data &/or key pattern matches on disk ... w/o having to know specific location for some piece of information. this was used extensively in various kinds of directories (kept on disk w/o needing to use extremely scarce real storage).

however the 60s era databases tended to have direct record pointers exposed in database records (independent of the multi-track "searching" operations which would tell the disk to try and find the record).

i've posted several times before about the discussions between the ims group in stl/bldg90 and the (original relational/sql) system/r group in sjr/bldg28 (where codd was located). misc. past posts mentioning system/r
http://www.garlic.com/~lynn/subtopic.html#systemr

the ims group pointed out that the index implementation in relational (which contributed to eliminating exposed record pointers as part of the database schema) typically doubled the physical disk space ... vis-a-vis ims ... and greatly increased the number of physical disk i/os (as part of processing the index to find actual record location). the relational counter-argument was that eliminating the exposed record pointers as part of the database schema significantly reduced the administrative and management costs for large complex databases.

going into the 80s, there was significant increases in availability of electronic stoarge and also significant decline incomputer hardware costs (especially compared to increasing people costs). this shift helped with the uptake of relational ... the reduction in disk costs (and significant increase in bytes/disk) eliminated much of the argument about the disk space requirements issue for relational index. The increases in sizes of computer memories (and reduction in cost) allowed for significant amounts of relational indexes to be cached in real storage (mitigating the significant increase in i/os that had been needed to process the indexes). The significant reduction in administrative and management for relational (vis-a-vis ims) was not only a cost issue but also became a skills availability issue (it became much easier to obtain and justify skills for relational deployment).

the database direct record pointers as well as the extensive "searching" capability (both from the 60s) could be considered a result of the extremely constrained amount of available system memory/storage.

the shift in relative amounts of system memory/storage vis-a-vis i/o capacity actually started by the mid-70s. in the early 80s, I was making statements that relative disk thruput had declined by better than an order of magnitude (ten times) over a period of 10-15 yrs (i.e. memory and cpu had increased by a factor of 40-50, disk thruput had only increase by factor of 3-5). this got me into some amount of trouble with the executives that ran the disk division. at one point they assigned their performance group to refute my statements. after a couple of weeks ... they came back and observed that I had actually somewhat understated the technology shift. on the other hand ... they did let me periodically play disk engineer in the disk engineering and product test labs ... misc. past posts
http://www.garlic.com/~lynn/subtopic.html#disk

other purely historical topic drift ... the first relational product was for Multics ... from the 5th flr at 545 tech sq.

the science center was on the 4th flr of 545 tech sq. http://www.garlic.com/~lynn/subtopic.html#545tech

which had come up with the original virtual machine operating systems ... thru various generations cp40, cp67, vm370, etc. it was also where (gml) markup language was invented in 1969 (subsequently morphing in various sgml, html, xml, etc).

and all the system/r development was done on vm370 virtual machine operating system at sjr.

the march in the increases in system real storage has seen another transition. relational implementations during the 70s and 80s were mostly oriented towards primary location of information was on disk and copies were kept cached in real storage. however, in the 90s there started appearing implementations that assumed the whole database was in real storage and disks were purely for transaction integrity.

these claimed ten times the performance of the earlier generation of "caching" oriented implementations (even on the same hardware where the caching oriented implementations had their complete database also resident in real storage).

these high-performance relational databases saw some uptake in the telco and cellphone markets ... used for large number of call detail/charge records. there was also some speculation in this period that telcos might be able to move into the payment transaction market ... leveraging their highly efficient call transaction database implementations to first gain a foothold with "micro-payments" and then moving into the rest of the payment transaction market (being able to process significantly larger volume of transactions at a significantly lower cost). the big inhibitor for telcos pulling this off seems to be figuring out how to deal with the financial liability issues with regard to handling payments. Received on Tue May 20 2008 - 21:37:52 CEST