[AccessD] Primary Key Best Practices

Jim Lawrence accessd at shaw.ca
Sun Jul 29 12:32:12 CDT 2007


Well said Charlotte. 

To give ground is dishonorable and it death before dishonor. :-)

Jim 

-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Charlotte Foust
Sent: Thursday, July 26, 2007 9:28 AM
To: Access Developers discussion and problem solving
Subject: Re: [AccessD] Primary Key Best Practices

Ah, yes, the classic AccessD  method for conquering opposition:
willfully misinterpret the responses, deny them any validity, and
declare yourself the winner!   Widely used by Colby and by Drew on
occasion.  It amounts to "never mind if we're saying much the same
thing, you're WRONG!!"  LOL

Charlotte Foust

-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby
Sent: Thursday, July 26, 2007 5:58 AM
To: 'Access Developers discussion and problem solving'
Subject: Re: [AccessD] Primary Key Best Practices

>From Charlotte:

>>You'd still need an identity field to edit it in SQL Server.

<<No, in fact you do not!>>

>  Yes, you do.  The true purpose of a primary key is to uniquely 
> identify a
row.

No JIM, you DO NOT.

Go to SQL Server (I did!)
Create a new table - just two rows is fine (I did) Create two fields (I
did) DO NOT create any index whatsoever (I did not) Do NOT create a PK
(I did not) Open the table (I did) Enter data (I did) Move off the
record so that it stores (I did) Do a couple of more (I did) Edit
records (I did) DELETE records (I did)

LISTEN VERY CAREFULLY JIM.  YOU DO !!!!NOT!!!! HAVE TO HAVE A PK TO DO
ANY OF THE THINGS YOU MENTIONED.

I have actually done this, apparently you have not.  You can have
duplicate data, you can have unique data (with a caveat in SQL Server -
see below), it simply does NOT MATTER.  You can add, edit and delete
records in a table in SQL Server without having any keys, candidate or
otherwise, and without having any indexes.

You need to get off it for a minute and admit that while the model is
nice in fact NO RDBMS actually IMPLEMENTS the model.  I don't know about
you but I actually live in reality and it is important to understand
what REALLY HAPPENS out here in the real world.

By "your" definition - a candidate key or a PK (which has to be a
candidate
key) is any field or combination of fields where the data stored in the
fields is unique within the table and can therefore be used to uniquely
identify the row.

YOU can create a table (though you may refuse to do so in order to
avoiding admitting this, but I HAVE DONE SO) where there is NO candidate
key or PK, and in fact the data in those two fields are exactly the same
in some records.  You CAN still edit data directly from inside of SQL
Server.  You can still add records (programmatically with a query), you
can still delete records (programmatically with a query), you can still
edit records (programmatically, with a query).

JIM, I HAVE DONE THIS!

You do NOT have to have a PK in order to do ADD EDIT OR DELETE rows in a
REAL LIFE record in a REAL LIFE DATABASE, and MODEL BE DAMNED!  If the
model LIES, then it is time to pay more careful attention to reality.
Models MODEL reality, not vice versa.

NOW... 

Make two rows in the table identical.  SQL Server complains (Access does
not btw).  You CAN move off of the record, storing the data.  However
you cannot delete OR EDIT either record (in SQL Server you are screwed
apparently, you CAN in Access).  You CAN still add new records though
(even in SQL Server), and you CAN edit those OTHER records as long as
those other records are unique, even in SQL Server.  

What does this prove?  SQL Server has a bug, whereas Access does not.
Any way you look at it, SQL Server has a bug, either in allowing the
identical data to store, or not allowing the data to be edited later.

Notice that:

1) The data STORED whether or not it was unique.
2) EVEN with non unique records in place, more data could be added,
edited and deleted (even in SQL Server).
3) Access could delete or modify the data, even the records where the
data is not unique, SQL could not.

Now, scream all you want Jim, but facts is facts and REAL DBMSs do NOT
require a candidate key or a PK in order to add, delete or edit the data
in a table.  BY YOUR OWN DEFINITION, a PK or candidate key is one where
ALL THE DATA in a field or set of fields is unique.  BOTH Access and SQL
Server can add records, wither the data is unique or not.  BOTH
databases can add new records whether or not there is data in the table
that prevents defining a candidate key or a PK.  ACCESS can edit data
even in records where the data is exactly the same as another record.

JIM, I HAVE DONE THIS!

You do NOT have to have a PK in order to ADD EDIT OR DELETE rows in a
REAL LIFE record in a REAL LIFE TABLE in a REAL LIFE DATABASE, and MODEL
BE DAMNED!  If the model LIES, then it is time to pay more careful
attention to reality.  Models MODEL reality, not vice versa.

YOU CLAIM that without a PK you cannot edit data in a relational
database.
YOU CLAIM that a PK is by necessity a field or set of fields where the
data is unique throughout the table.  I HAVE PROVEN that your claims are
not true!

Go ahead Jim, sputter away about how reality doesn't correctly implement
the model, that is true, and that is irrelevant.  Reality is, and NO
RDBMS correctly implements the model in all aspects, and you know that.

And (to the immense relief of everyone I am sure) I am SOOOOO done with
you and your model and this discussion.

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 Jim Dettman
Sent: Thursday, July 26, 2007 7:28 AM
To: 'Access Developers discussion and problem solving'
Subject: Re: [AccessD] Primary Key Best Practices

<<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

--
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com

--
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com

-- 
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com




More information about the AccessD mailing list