Is it best to join as many primary keys to ther tables as possiable?

[eeps24]

I have 3 questions if someone can please explain regarding joining primary keys to other tables.



1. lets say theres (for example) 10 primary keys that exist on table A and table B. Is it best to join all 10, or would joining fewer have better results?

2. (on the picture I posted below) Notice the red arrow pointing to the field "po_number" on table dbo_mainvmsg and dbo_mainvdtl. Its a primary key only on 1 table, do you still join that because its a primary key?

3. (on the picture I posted below) notice the red arrow pointing to the field "item" on table dbo_mainvdtl and dob_poline. This is not a primary key on either table, would I still join them? Or is joining only for primary keys?

Thank you

[orange]

You need to review and understand normalization and relationships.
Normalization UA Normalization

Relationships
UniqueCompositeIndexes

[eeps24]

Thank you Orange for those links, I will certainly read them but I was wondering if there was a quick answer to those questions? As I am in the middle of working on this report thats giving me an issue.

[orange]

There is only 1 primary key per table. It may be a composite primary key meaning that it is made up of 2 or more fields.

It is difficult to answer your specific questions without knowing something about
a) your business, and
b)where the database relationships in the diagram came from.

In related tables, you would normally have a Primary key in Table X, and Foreign key in Table Y.
This indicates that each record in Table X is uniquely identified by the Primary key value. All records in table Y that relate to a record in Table X have the same value of the Primary Key(table X) in the foreign key field in Table Y.

Now based on your 3 questions:

1 NO - join PK and FK to get matching records
2 "
3 "

[Homegrownandy]

Oranges answer is the best. You don't understand how the relationships work and why we need the keys.

The key is the unique field in a table used to reference specific records.

EG. A contact works for a company. the company has many staff (contacts) so its a good idea to store the data about the company separately from its staff.

on the contacts table you have specific details about the contact, then you reference the company he works for using the key from company.

company 1 (company_ID) = company details (whatever you want to store about the company. )

then in contacts.. have whatever info you want then reference the company using the ID. in the contacts form have a field called company ID and match it up. its simple.

In forms you can click the company name and still in the tables the ID is stored not the lengthy data such as the address.


that's a bit long winded and probably hard to follow but.. the keys just link information. so you have less data. you only ever need one link between data. although there can be several ways to achieve that link.

[Homegrownandy]

I feel bad for you mate, it looks like you have done a lot.

[eeps24]

Thank you guys I have to digest this information. I guess Joining primary keys to primary keys was a bad idea. I should be primary to foreign.

[orange]

Primary to foreign provided there is a relationship between the "entities"/tables. It is your business facts that determines relationships.

[Homegrownandy]

there's a few short youtube series that would help you a lot.