RE: No primary keys

You may be getting caught up in semantics. Yes, the root 'reference' is a much better word, but we like using fewer syllables. I don't think anybody else in this group cares. Secondly, the 'key' that all tables must have as part of their basic definition... I can imagine that a page address+slot may be what you are referring to, but there is certainly no restriction in practice within Informix as to whether you have to define an index on a table or not. To wit, I have several large tables here in production without indices. Yes, each row within the table does in fact have some method within the raw data of being identified, however I never refer to individual rows within these tables and thus don't need indices. If I had indices the optimizer would occasionally think it were more appropriate to use nested loops instead of hash joins which would be a catastrophic thing. cheers j. > -----Original Message----- > From: Joe Celko [mailto:71062.1056@compuserve.com] > Sent: Tuesday, January 09, 2001 11:08 AM > To: informix-list@iiug.org > Subject: Re: No primary keys > > > > >> Child tables need no primary key, only parent tables do. << > > First of all, the terms I think you meant to use are "referenced" > and "referencing" tables. There is no such thing as a child > and parent > table in SQL; those terms are from the days of pointer chains in > hierarchical and network databases. > > Secondly, wrong! ALL tables, to be tables, have to have a key. That > is a basic definition. This is very valid generic advice. > > --CELKO-- > Joe Celko, SQL Guru & DBA at Trilogy > When posting, inclusion of SQL (CREATE TABLE ..., INSERT ..., etc) > which can be cut and pasted into Query Analyzer is appreciated. > > > Sent via Deja.com > http://www.deja.com/ >