As a rule is it better to use native primary keys (ie existing columns or combination of columns) or set your primary key to an auto generating row of integers?
This is a pretty common topic.
A primary key
Ideally, you use an artificial (surrogate) key for your rows, a numeric integer data type (INT) is best, because space-efficient and fast.
A primary key should be made of the minimum number of fields to still fulfill conditions 1.-3. For vast majority of tables this minimum is: 1 field.
For relation tables (or very special edge cases), it may be higher. Referencing a table with a composite primary key is cumbersome, so a composite key is not recommended for a table that must be referenced on it's own.
In relation tables (m:n relations) you make a composite key out of the primary keys of the related tables, hence your composite key automatically fulfills all three conditions from above.
You could make primary keys out of data if you are absolutely sure, that it will be unique and will never change. Since this is hard to guarantee, I'd recommend against it.
Whatever it is, make it non meaningful (surrogate key). Meaningful primary keys are deadly.
Always ints.
You'll appreciate you did so when it's time to cross reference those elements in other tables (using foreign keys)
I would say auto generating, theres no real reason not to in my mind. Unless your developing some kind of hash table, but even so, I would stick to a unique primary key automatically created by the database. Its quick, simple and reliable. Don't reinvent the wheel if its already there.
It is an old war between purists and pragmatists. Purists don't accept surrogate primary keys and insist on using only natural ones. If you ask me, I'll vote for increment (surrogate keys) in most of situations.