Topic awaiting preservation: When don't I need the primary key of table???

Hi, guys. May I ask you something, please?
I sometimes design table to create business apprecations.
I am newbie of this industory.
I sometimes found tables which does not include primary key.
I wonder when I don't need the primary key.
Any your comments about this will be highly appreciated.
Thanks.

You wouldn't need a primary key if the table exsist by itself and/or if it is never referenced or shared data from another table.

Hi, Mal. Thanks for that.
But the last bit of your comments.

quote:

---

if it is never referenced or shared data from another table.

---

Do you mean that Table has to have the PK when I want to join the table???
And why is that???

Primary keys are unique identifiers for a row in the table. If you don't have one, when you do a join you don't have a unique way of identifying a particular row in the table.

Another place you usually won't have one is relational tables which are usually just rows of Primary Keys. For example if you have a table of students and a table of classes then a third table of students and classes which only contains the Primary Key for a student and a the primary key of a class. You'd use the student table to get the student info, the class table to get the class info and the student/class table to find out which students are in which classes.



.:[ Never resist a perfect moment ]:.

Thanks a lot but let me say a wee bit more, BD.
So when I do a join I will not need the primary key only when each table's row has absolute unique data, right?
Thanks.

The absolute unique data is what you would declair the primary key.

In bitdamaged's example, the first 2 tables he mentioned (students and classes) would both have a field that was a primary key. This key would quite often be an auto increment ID column. The table that wouldn't need a primary key would be the third table because this table would be used to relate the fisrt 2 tables together. It would probably hold just 2 fields 'students' and 'classes' and would hold an ID from each of the other 2 tables and be used in queries to relate the other 2 tables together.

I hope that helped.

-Butcher-

Wow... I just had my DB class last semester. I wish you had the teacher I did. He pounded all this info into us and the book that went along with it was great. Before you start rambling off questions and expecting easy answers, can I ask if you have sat down and read a book yourself about relational databases. This may be your best solution and provide answers in a more orderly fashion. I don't mean to say this to be rude but I don't want to give you my few thousand dollars in education in a few threads. If I had to suffer for 6+ months to learn this then you should at least do some reading before taking the easy way out. Or at least tell me a specific issue where this is coming up for you.

Also, setting a primary key is not a big task. What would be your reasoning for not wanting one?



(Edited by MalFunkShun on 08-12-2004 20:11)

You don't need primary keys, you want primary keys. They are the identifiers used to make a row in a table unique. When you do a join you are going to get a SQL result set with a number of rows. Without using a primary key there's nothing to distinguish the rows so you're just going to have a chunk of data that you can't really do much with.



.:[ Never resist a perfect moment ]:.