Re: does a table always need a PK?

"Heikki Tuuri" <Heikki.Tuuri_at_innodb.com> wrote in message news:<p972b.357$yu.174_at_read3.inet.fi>...
> Hi!
>
> I would like to bring up to the discussion what I remarked in the other
> discussion thread on MySQL RDBMSness.
>
> If we have a quantum mechanical system where electrons are
> indistinguishable, would it not be natural to create a table of electrons
> without a primary key?
>

Warning: I have read only one of the replies to your question, but here is my take:

The general purpose of a database is to store data that can be used later for some reason. Usually the reason involves having separate records that are in some way (even if slightly) different from each other. I think it is even in the very nature of table design that the entity that forms the basis for the table is made to model a logically related group of data. (Yes all people are human, but they are all human in their own way, and that is what makes the data about them interesting. Thus a "people" table will contain name, address, height, and other pieces of data that will vary from person to person.)

So, to the extent that you would want to keep information in a database pertaining to a group of electrons that are otherwise indistinguishable, you would need assign *some* number to them to tell them apart in the database. Otherwise there is no reason at all to have a database in the first place; you could simply work with an aggregate total number of electrons and not worry about which one was which. (Yes, according to your example, all electrons are the same, but there must be something different about some electrons that must make it worth it to go to the trouble of making table records for them -- to wit, there is a limit to how many electrons can be in one place at one time, is there not? So that might apply in cases where you assign data values of electron_time and electron_position which will definitely vary from record to record.)

Just my two cents!

Regards,
Shepherdmoon

> Best regards,
>
> Heikki Tuuri
> Innobase Oy
>
>
> "--CELKO--" <joe.celko_at_northface.edu> kirjoitti viestissä
> news:a264e7ea.0308231444.3179b3a3_at_posting.google.com...
> > >> do I need to have a primary key in the BOOK table? <<
> >
> > Yes, otherwise it is not a table by definition. Assuming that you
> > have more than one book, use the ISBN as the industry standard
> > identifier and use this table:
> >
> > CREATE TABLE Books
> > (isbn CHAR(10) NOT NULL,
> > page_nbr INTEGER NOT NULL,
> > content TEXT NOT NULL,
> > PRIMARY KEY (isbn, page_nbr));
> >
> > if you had only one book, use its title for the table name:
> >
> > CREATE TABLE "Moby Dick"
> > (page_nbr INTEGER NOT NULL PRIMARY KEY,
> > content TEXT NOT NULL);
> >
> > You are splitting attributes in the original schema. That is, you put
> > the attributes of a book in (n > 1) table, so the data model was not
> > complete.
Received on Tue Aug 26 2003 - 21:42:14 CEST