phpMyAdmin and relational database

oaskedal

Hi!

I'm a bit stuck. I am trying to put up a test system (prototype school project) and I try to use phpMyAdmin to setup a relational database.

I'm fairly new in database knowledge 😕, but as I've understood the indexing part in phpMyAdmin requires the same datatype in both tables to work in a relational way. If the PRIM KEY is an INT in tab 1, then the SEC.KEY must be an INT in tab 2?

Now, what if my primary key in my tab 1 is a combination of two attributes with different datatypes, i.e. VARCHAR and INT? How can I setup this in my second tables SECONDARY KEY, and still manage the relations updating automatically? What datatype to choose??

Also, what's the opinion on using surrogat keys instead of natural ones in phpMyAdmin, as I find them so much easier to deal with in a relational way?

laserlight

oaskedal wrote:
but as I've understood the indexing part in phpMyAdmin requires the same datatype in both tables to work in a relational way. If the PRIM KEY is an INT in tab 1, then the SEC.KEY must be an INT in tab 2?

I am not entirely sure what you mean by SEC.KEY. It does not sound like you are talking about an index that serves as a secondary key, but rather like you are talking about a foreign key. If so...

oaskedal wrote:
Now, what if my primary key in my tab 1 is a combination of two attributes with different datatypes, i.e. VARCHAR and INT? How can I setup this in my second tables SECONDARY KEY, and still manage the relations updating automatically? What datatype to choose??

You would choose the exact same data types for the combined key.

oaskedal wrote:
Also, what's the opinion on using surrogat keys instead of natural ones in phpMyAdmin, as I find them so much easier to deal with in a relational way?

My lecturers did not really like using surrogate keys unnecessarily, but in practice I found that it is usually easier to refer to something using a number that can be say, concisely passed via the query string.

oaskedal

Thanks for your reply :-) I got it all sorted out now :-)

PS! Yeap, meant foreign key, not secondary key - my mistake...