Jim Dettman
jimdettman at verizon.net
Thu Jul 26 06:28:19 CDT 2007
<<No, in fact you do not!>> Yes, you do. The true purpose of a primary key is to uniquely identify a row. You may not have indicated in the RDBMS system a single index or that any field or fields is a "PK" for the relation, but you are still using one anytime you add or edit the data. The question is: If your going to edit a row, how do you as a user identify which row it is that you need to change? You use the data in the fields combined in a certain way to know that you are editing the correct row. It may mean that you might have to use every field (what is sometimes called a super-key), but you do use a key even if you have not defined one in the RDBMS. If you cannot identify a row uniquely, then storing the data is basically meaningless. This goes to the heart of the point that I was making that a "primary key" is much more then a pointer. It relates to the meaning of the data, not how it's stored. Jim. -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby Sent: Wednesday, July 25, 2007 7:56 PM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Primary Key Best Practices Charlotte, >You'd still need an identity field to edit it in SQL Server. No, in fact you do not! I have all these huge 1 table databases that I am currently using. They are lists of people / addresses / information about the people. They stand alone, at least initially. I always create an ANPK but... I just created a table in SQL server consisting of two fields char(10), text1 and text2. I saved the table, then I opened the table and edited the data, directly in SQL Server. No PK, I could edit the data. I entered new data records, I went back and edited existing data. I deleted rows. I can do any of the things that you are saying cannot be done, with out a PK, or even an index. Just plain old simple char() fields. Not an index in sight, never mind a unique index. No PK. I can add records, I can edit existing records, I can delete records, directly in the table in SQL Server. In fact my client used these huge data tables (lists of addresses) to create name / address lists that they sold to their clients long before I ever hit the scene. Just one table. They did not understand nor care about PKs. There were no child tables so no pointer was needed to get back to the parent. No unique index can be created, because there are in fact duplicates. They create hashes in order to discover and get rid of the duplicates in the output but there is no field, nor combination of fields that uniquely identify a specific record. The client uses (makes a LOT OF MONEY) off of these tables. Is this a database? I can't answer that. It is a standalone (extremely large) table in a big iron database management system. It generates millions of dollars a year for the owners. They do not in fact ever edit it, but they could if they wanted to, at least inside of SQL Server. John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Charlotte Foust Sent: Wednesday, July 25, 2007 5:50 PM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Primary Key Best Practices You're picking nits, John. You'd still need an identity field to edit it in SQL Server. If the unique key exists, you have a functional PK, whether you call it that or not. Charlotte Foust -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby Sent: Wednesday, July 25, 2007 2:47 PM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Primary Key Best Practices Any database made up of a single table would not require a PK. John W. Colby Colby Consulting www.ColbyConsulting.com -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com