 | |
#771
 
| |||
| |||
|
Re: pro- foreign key propaganda? -
06-04-2008
, 09:24 AM
|
David Cressey wrote: ... Your guess is as good as mine, maybe better. But my guess is different. I believe the word "key" was as unhooked from "address" as any term of the day. I don't know a thing about IMS. For several indexed file systems, the keys were fraught with navigational consequences, but this was *not* because they were something other than data. The keys were just as much data as they were in the 1970 paper. In fact, when I was easing my way towards RDBMSes, I spent some time using indexed files, keys, foreign keys, and relational joins without the benefit of any DBMS. It's remarkable how much of "relational think" can be transposed to index files with little, if any, loss of conceptual clarity. Yeah, I remember in the 1980's Unix had a file-based 'join' command. Not to criticize anybody, such as the physicists you mentioned - I have some sympathy for 'outsiders' who refuse to accept IT dogma and cause a course change in the computer field. But looking back on the data field's history, it is really just a series of stumbles and meanders, once in a while the latest direction looks sensible but is soon usurped with more chaos. In the IBM way of things (which was cloned by several other mfrs, not just the mainframe ones, but even Wang, IIRC), there was this thing called Count-Key-Data disk architecture and a bunch of 'access methods' (which IMS made use of, but could be used by themselves without IMS). Likely I recall some of the details wrong, but keys in access methods such as VSAM or ISAM or even BDAM if I recall, below any logical schemes such as trees, could be stored in segregated disk cylinders and there were also little mini-computers called channels with very limited instruction sets which would search those disk cylinders asynchronously from the main cpu. (Some of those artifacts found their way into the higher-level IMS configuration verbiage and commands.) All the 'bare-metal' programmers knew about this as well as many other physical techniques such as how to avoid hardware deadlocks. Much of Codd's audience was within this (dominant) culture and he was very much addressing it. (Codd was a pragmatist for sure - twenty years after his first paper, he was making consulting bucks that would embarrass even the greediest senior law partners but was still willing to become architect of an obscure, non-relational product. Money wasn't at issue, just the choice of job titles between a couple of large egos put the kibosh on that deal.) |
you know that Ted Codd moved to Ottawa as a protest of McCarthy? But I get
sidetracked. You cannot (by definition) have a RM without foreign keys.
Physical and logical, you need the damn things..
Evan
#772
| |||
| |||
|
|
David Cressey wrote: ... Your guess is as good as mine, maybe better. But my guess is different. I believe the word "key" was as unhooked from "address" as any term of the day. I don't know a thing about IMS. For several indexed file systems, the keys were fraught with navigational consequences, but this was *not* because they were something other than data. The keys were just as much data as they were in the 1970 paper. In fact, when I was easing my way towards RDBMSes, I spent some time using indexed files, keys, foreign keys, and relational joins without the benefit of any DBMS. It's remarkable how much of "relational think" can be transposed to index files with little, if any, loss of conceptual clarity. Yeah, I remember in the 1980's Unix had a file-based 'join' command. Not to criticize anybody, such as the physicists you mentioned - I have some sympathy for 'outsiders' who refuse to accept IT dogma and cause a course change in the computer field. But looking back on the data field's history, it is really just a series of stumbles and meanders, once in a while the latest direction looks sensible but is soon usurped with more chaos. In the IBM way of things (which was cloned by several other mfrs, not just the mainframe ones, but even Wang, IIRC), there was this thing called Count-Key-Data disk architecture and a bunch of 'access methods' (which IMS made use of, but could be used by themselves without IMS). Likely I recall some of the details wrong, but keys in access methods such as VSAM or ISAM or even BDAM if I recall, below any logical schemes such as trees, could be stored in segregated disk cylinders and there were also little mini-computers called channels with very limited instruction sets which would search those disk cylinders asynchronously from the main cpu. (Some of those artifacts found their way into the higher-level IMS configuration verbiage and commands.) All the 'bare-metal' programmers knew about this as well as many other physical techniques such as how to avoid hardware deadlocks. Much of Codd's audience was within this (dominant) culture and he was very much addressing it. (Codd was a pragmatist for sure - twenty years after his first paper, he was making consulting bucks that would embarrass even the greediest senior law partners but was still willing to become architect of an obscure, non-relational product. Money wasn't at issue, just the choice of job titles between a couple of large egos put the kibosh on that deal.) |
you know that Ted Codd moved to Ottawa as a protest of McCarthy? But I get
sidetracked. You cannot (by definition) have a RM without foreign keys.
Physical and logical, you need the damn things..
Evan
#773
| |||
| |||
|
|
David Cressey wrote: ... Your guess is as good as mine, maybe better. But my guess is different. I believe the word "key" was as unhooked from "address" as any term of the day. I don't know a thing about IMS. For several indexed file systems, the keys were fraught with navigational consequences, but this was *not* because they were something other than data. The keys were just as much data as they were in the 1970 paper. In fact, when I was easing my way towards RDBMSes, I spent some time using indexed files, keys, foreign keys, and relational joins without the benefit of any DBMS. It's remarkable how much of "relational think" can be transposed to index files with little, if any, loss of conceptual clarity. Yeah, I remember in the 1980's Unix had a file-based 'join' command. Not to criticize anybody, such as the physicists you mentioned - I have some sympathy for 'outsiders' who refuse to accept IT dogma and cause a course change in the computer field. But looking back on the data field's history, it is really just a series of stumbles and meanders, once in a while the latest direction looks sensible but is soon usurped with more chaos. In the IBM way of things (which was cloned by several other mfrs, not just the mainframe ones, but even Wang, IIRC), there was this thing called Count-Key-Data disk architecture and a bunch of 'access methods' (which IMS made use of, but could be used by themselves without IMS). Likely I recall some of the details wrong, but keys in access methods such as VSAM or ISAM or even BDAM if I recall, below any logical schemes such as trees, could be stored in segregated disk cylinders and there were also little mini-computers called channels with very limited instruction sets which would search those disk cylinders asynchronously from the main cpu. (Some of those artifacts found their way into the higher-level IMS configuration verbiage and commands.) All the 'bare-metal' programmers knew about this as well as many other physical techniques such as how to avoid hardware deadlocks. Much of Codd's audience was within this (dominant) culture and he was very much addressing it. (Codd was a pragmatist for sure - twenty years after his first paper, he was making consulting bucks that would embarrass even the greediest senior law partners but was still willing to become architect of an obscure, non-relational product. Money wasn't at issue, just the choice of job titles between a couple of large egos put the kibosh on that deal.) |
you know that Ted Codd moved to Ottawa as a protest of McCarthy? But I get
sidetracked. You cannot (by definition) have a RM without foreign keys.
Physical and logical, you need the damn things..
Evan
#774
| |||
| |||
|
|
David Cressey wrote: ... Your guess is as good as mine, maybe better. But my guess is different. I believe the word "key" was as unhooked from "address" as any term of the day. I don't know a thing about IMS. For several indexed file systems, the keys were fraught with navigational consequences, but this was *not* because they were something other than data. The keys were just as much data as they were in the 1970 paper. In fact, when I was easing my way towards RDBMSes, I spent some time using indexed files, keys, foreign keys, and relational joins without the benefit of any DBMS. It's remarkable how much of "relational think" can be transposed to index files with little, if any, loss of conceptual clarity. Yeah, I remember in the 1980's Unix had a file-based 'join' command. Not to criticize anybody, such as the physicists you mentioned - I have some sympathy for 'outsiders' who refuse to accept IT dogma and cause a course change in the computer field. But looking back on the data field's history, it is really just a series of stumbles and meanders, once in a while the latest direction looks sensible but is soon usurped with more chaos. In the IBM way of things (which was cloned by several other mfrs, not just the mainframe ones, but even Wang, IIRC), there was this thing called Count-Key-Data disk architecture and a bunch of 'access methods' (which IMS made use of, but could be used by themselves without IMS). Likely I recall some of the details wrong, but keys in access methods such as VSAM or ISAM or even BDAM if I recall, below any logical schemes such as trees, could be stored in segregated disk cylinders and there were also little mini-computers called channels with very limited instruction sets which would search those disk cylinders asynchronously from the main cpu. (Some of those artifacts found their way into the higher-level IMS configuration verbiage and commands.) All the 'bare-metal' programmers knew about this as well as many other physical techniques such as how to avoid hardware deadlocks. Much of Codd's audience was within this (dominant) culture and he was very much addressing it. (Codd was a pragmatist for sure - twenty years after his first paper, he was making consulting bucks that would embarrass even the greediest senior law partners but was still willing to become architect of an obscure, non-relational product. Money wasn't at issue, just the choice of job titles between a couple of large egos put the kibosh on that deal.) |
you know that Ted Codd moved to Ottawa as a protest of McCarthy? But I get
sidetracked. You cannot (by definition) have a RM without foreign keys.
Physical and logical, you need the damn things..
Evan
#775
| |||
| |||
|
|
David Cressey wrote: ... Your guess is as good as mine, maybe better. But my guess is different. I believe the word "key" was as unhooked from "address" as any term of the day. I don't know a thing about IMS. For several indexed file systems, the keys were fraught with navigational consequences, but this was *not* because they were something other than data. The keys were just as much data as they were in the 1970 paper. In fact, when I was easing my way towards RDBMSes, I spent some time using indexed files, keys, foreign keys, and relational joins without the benefit of any DBMS. It's remarkable how much of "relational think" can be transposed to index files with little, if any, loss of conceptual clarity. Yeah, I remember in the 1980's Unix had a file-based 'join' command. Not to criticize anybody, such as the physicists you mentioned - I have some sympathy for 'outsiders' who refuse to accept IT dogma and cause a course change in the computer field. But looking back on the data field's history, it is really just a series of stumbles and meanders, once in a while the latest direction looks sensible but is soon usurped with more chaos. In the IBM way of things (which was cloned by several other mfrs, not just the mainframe ones, but even Wang, IIRC), there was this thing called Count-Key-Data disk architecture and a bunch of 'access methods' (which IMS made use of, but could be used by themselves without IMS). Likely I recall some of the details wrong, but keys in access methods such as VSAM or ISAM or even BDAM if I recall, below any logical schemes such as trees, could be stored in segregated disk cylinders and there were also little mini-computers called channels with very limited instruction sets which would search those disk cylinders asynchronously from the main cpu. (Some of those artifacts found their way into the higher-level IMS configuration verbiage and commands.) All the 'bare-metal' programmers knew about this as well as many other physical techniques such as how to avoid hardware deadlocks. Much of Codd's audience was within this (dominant) culture and he was very much addressing it. (Codd was a pragmatist for sure - twenty years after his first paper, he was making consulting bucks that would embarrass even the greediest senior law partners but was still willing to become architect of an obscure, non-relational product. Money wasn't at issue, just the choice of job titles between a couple of large egos put the kibosh on that deal.) |
you know that Ted Codd moved to Ottawa as a protest of McCarthy? But I get
sidetracked. You cannot (by definition) have a RM without foreign keys.
Physical and logical, you need the damn things..
Evan
 |
« Previous Thread
|
Next Thread »
| Thread Tools | |
| Display Modes | |
Linear Mode
| |
Powered by vBulletin Version 3.5.3
Copyright ©2000 - 2012, Jelsoft Enterprises Ltd.
Copyright ©2000 - 2012, Jelsoft Enterprises Ltd.