Re: No primary keys

> Go back to basics. The real problem is that you do not have a table at > all -- no key, no table. You have a multi-set. Access to the data > will be horrible unless you add an index. But that is nothing > compared to the potential logical problems you will (have) made > for yourself. > > These things should be constructed only as "holding tanks" for data, > used to scrub the data, then move it to a "proper table" that you > actually use for the applications. There you go again, confusing SQL religion with Informix syntax. Informix requires us to refer to "multi-sets" as "tables," despite the anguish this may cause you. Your world view seems to include mostly OLTP. Fine, but realize that there are other views out there. Oops, I'm sorry, "view" is a SQL keyword isn't it. Well, I hope you understand what I'm getting at anyway. You may be surprised to learn that in some cases, data access can actually be worsened by the creation of explicit primary key indexes on data. In the real world, optimizers don't always make the "correct" choice, and accessing data through an index that would be better accessed sequentially can be just as "horrible" as accessing data sequentially that would be better accessed via an index. Not to mention, you've got to take the time and disk space to build the index. -cs Sent via Deja.com http://www.deja.com/

And you are still confusing the implementation mechanisms that Informix uses to maintain and inforce primary key uniqueness with the concept of a primary key which simpley means that each table has to have a set of columns whose values can uniquely identify a single row. This is the primary key (lower case) that Joe is referring to NOT the PRIMARY KEY CONSTRAINT (upper case). Art S. Kagel cedarsiding@my-deja.com wrote: > > > Go back to basics. The real problem is that you do not have a table at > > all -- no key, no table. You have a multi-set. Access to the data > > will be horrible unless you add an index. But that is nothing > > compared to the potential logical problems you will (have) made > > for yourself. > > > > These things should be constructed only as "holding tanks" for data, > > used to scrub the data, then move it to a "proper table" that you > > actually use for the applications. > > There you go again, confusing SQL religion with Informix syntax. > Informix requires us to refer to "multi-sets" as "tables," > despite the anguish this may cause you. > > Your world view seems to include mostly OLTP. Fine, but realize > that there are other views out there. Oops, I'm sorry, "view" > is a SQL keyword isn't it. Well, I hope you understand what > I'm getting at anyway. > > You may be surprised to learn that in some cases, data access > can actually be worsened by the creation of explicit primary key > indexes on data. In the real world, optimizers don't always make > the "correct" choice, and accessing data through an index that > would be better accessed sequentially can be just as "horrible" > as accessing data sequentially that would be better accessed via > an index. Not to mention, you've got to take the time and disk > space to build the index. > > -cs > > Sent via Deja.com > http://www.deja.com/

My interpretation of what Joe said, was you must have a database defined key otherwise you don't have a table. Otherwise, he wouldnt have said > > > no key, no table. You have a multi-set. Access to the data > > > will be horrible unless you add an index. Just my take on the conversation. Will In article <3A5CE91D.7159901F@bloomberg.net>, kagel@bloomberg.net wrote: > And you are still confusing the implementation mechanisms that Informix > uses to maintain and inforce primary key uniqueness with the concept of a > primary key which simpley means that each table has to have a set of columns > whose values can uniquely identify a single row. This is the primary key > (lower case) that Joe is referring to NOT the PRIMARY KEY CONSTRAINT (upper > case). > > Art S. Kagel > > cedarsiding@my-deja.com wrote: > > > > > Go back to basics. The real problem is that you do not have a table at > > > all -- no key, no table. You have a multi-set. Access to the data > > > will be horrible unless you add an index. But that is nothing > > > compared to the potential logical problems you will (have) made > > > for yourself. > > > > > > These things should be constructed only as "holding tanks" for data, > > > used to scrub the data, then move it to a "proper table" that you > > > actually use for the applications. > > > > There you go again, confusing SQL religion with Informix syntax. > > Informix requires us to refer to "multi-sets" as "tables," > > despite the anguish this may cause you. > > > > Your world view seems to include mostly OLTP. Fine, but realize > > that there are other views out there. Oops, I'm sorry, "view" > > is a SQL keyword isn't it. Well, I hope you understand what > > I'm getting at anyway. > > > > You may be surprised to learn that in some cases, data access > > can actually be worsened by the creation of explicit primary key > > indexes on data. In the real world, optimizers don't always make > > the "correct" choice, and accessing data through an index that > > would be better accessed sequentially can be just as "horrible" > > as accessing data sequentially that would be better accessed via > > an index. Not to mention, you've got to take the time and disk > > space to build the index. > > > > -cs > > > > Sent via Deja.com > > http://www.deja.com/ > Sent via Deja.com http://www.deja.com/