Is there any need for primary key?
The purpose of a primary key, is to ensure each row is unique (no dupes), so that one may address each row individually.
If you need to ensure that no two rows are duplicate, and/or you need to be able to address one specific row (to edit or delete), then you need to have a way to uniquely identify that particular row. You can have the database do that for you with two different methods
1 - designate the field, or combination of fields as Primary Key
2 - establish a unique index on the field or combination of fields
Primary Key designation has a couple of interesting characteristics
1 - it determines the physical order in which the records are stored
2 - visually, field names are bold in relationship window and displays a key symbol in table design view
re 1 - Jet will store new records at "the end of the table", but reorder the table in primary key order when doing a compact/repair. In some situtations, PK vs unique index might be interesting in terms of for instance speed of retrieval or locking.
So, to the question whether a primary key will help you writing queries, the answer will be yes (either primary key or unique index), if the results depend on not having dupes.
One might argue that the ability to identify, add, edit or delete individual rows, are among the core reasons for using a database. Access, when using it's default database (Jet) is able to do such operations through the interface, even with duplicate rows, but of course not with SQL. If you fire off SQL to manipulate one of umpteen duplicate rows, you will affect them all (update/delete). If you need to be able to address a specific row with SQL, you need a primary key or unique index.
The next issue, is that if you foresee that this db at a point of time can be upsized to another platform, then you might want to know that if you link for instance to a SQL server database table without primary key and try to add, edit or delete, you will not succeed. If there's no unique field, primary key or unique index, the table is not updateable - you can only browse the data.
So, is it always a good idea to have a primary key? If you need to be able to add, edit and delete individual rows (which one might say are standard/usual requirements of database operation), regardless of manipulation method (SQL/interface) and platform, then you will need a unique index or primary key on the table.
If you don't care about dupes (or wish to allow dupes for some reason), you know that you'll never ever need to address individual rows through other means than the Access interface, and never ever will change database platform...
A side benefit of primary keys, is that one might use them when referencing tables (relationship between tables), but again, the main reason for primary keys, is to identify each row in the table where it is assigned. Anyway, you don't need to use the primary key for the referencing either, any field or combination of fields with unique index will do (i e any candidate key).
Let's say you're working with a junction table with a three-field composite primary key, and you suddenly need to establish a referencing table (child table). Creating a relationship on three fields is sometimes a bit awkward/cumbersome, so another way would be to add another column to the table, for instance an Autonumber, add a unique index on it, and use that (not the composite primary key) for the relationship.
