I am designing my database with MySQL. I will use surrogate key for all my tables. But I also want to keep the nature unique key really unique.
For example in my Customer table, I have a surrogate key which is an auto-increment number. There is also a customerUserName field which should be unique.
How can I enforce this to make sure each customerUserName field are different?
You can add a unique key constraint to your customerUserName field.
It will be something like this
ALTER TABLE Customer ADD CONSTRAINT UQ_Customer_customerUserName UNIQUE (customerUserName)
Related
This may sound confusing and or simple but..
If I use a foreign key from Table B in Table A, which has a separate primary key. Do I need to include Table A's primary key as a foreign key in Table B?
Thanks!
========================================================================
EDIT:
Okay, let me try and clarify my question a bit.
In the case above, should I use Taco_ID as a FK in Table 2? Or is does it completely unnecessary?
In general, you don't usually make foreign keys bidirectionally like that. If you do, it means that the two tables exist in a 1-to-1 relationship: Each taco has a type, and each taco type can only be used by one taco. If you have a relationship like this, there's not really any reason to have them in separate tables, they could just be additional columns in the same table.
Normally foreign keys are used for 1-to-many or many-to-many relationships.
A 1-to-many relationship would be if many different tacos can be of the same type. They each have Taco_Type_ID foreign key.
For a many-to-many relationship, you typically use a separate relation table.
CREATE TABLE Taco_Types (
Taco_ID INT, -- FK to Table1.Taco_ID
Taco_Type_ID INT, -- FK to Table2.Taco_Type_ID
PRIMARY KEY (Taco_ID, Taco_Type_ID)
);
foreign keys and primary keys are SOMETIMES related, but not always. A foreign key in a table literally just means "whatever value is in this field MUST exist in this other table over ---> here". Whether that value is a PK or not in that other table is irrelevant - it just has to exist, and it has to be unique. That may fit the bill of being a primary key, but being primary is NOT required.
You can have composite foreign keys, e.g. in a (silly) address book, the child table you list a person's phone numbers in COULD be keyed with (firstname, lastname), but that runs into the problem of "ok, which John Smith does this number belong to?".
In most databases, foreign key references must be to primary keys or unique keys (and NULLs are allowed). MySQL recommends this but does not require it:
However, the system does not enforce a
requirement that the referenced columns be UNIQUE or be declared NOT
NULL. The handling of foreign key references to nonunique keys or keys
that contain NULL values is not well defined for operations such as
UPDATE or DELETE CASCADE. You are advised to use foreign keys that
reference only UNIQUE (including PRIMARY) and NOT NULL keys.
Do you need to reference primary keys for a foreign key relationship? First, you don't even need to declare foreign key relationships. I think they are important because they allow the database to maintain referential integrity. But, they are not required. Nor is there any semantic difference in queries, based on the presence of foreign keys (for instance, NATURAL JOIN does not use them). The optimize can make use of the declared relationship.
Second, if you are going to declare the foreign key, I would recommend using the primary key of the referenced table. That is, after all, one of the major reasons for having primary keys.
In a MySQL database I have large amount of tables. there is not any foreign key relationships constraint but it could be done.
In my tables the foreign key field name and its equivalent primary key field both are the same.
I can guess the relations from this, but I want to add constraint to tables according to this convention.
is there any tool to do this? or may I write a script to do?
I'm creating a database and I'm not sure about one thing. I have an autoincrement primary key which I want to use as a foreign key. Should the foreign key also be autoincrement?
The foreign key field must not be auto-increment. Auto-increment values imply that the field is not a foreign-key.
The purpose of auto-increment attributes is to generate a unique identity for new rows in the current table. The purpose of foreign keys is to uniquely identify rows in another table. They are very different things and you should read more about both and properly understand the difference.
Auto-increment allows a unique number to be generated when a new record is inserted into a table.
I have a table that has a primary key and a unique key.
From another table, is it possible to reference this unique key just the way Primary Key's and Foreign Keys are referenced & used ?
Would like to define this in the SQL definitions so that data correlations between these two tables are automatically cross referenced.
Foreign keys specifically state they only need a unique and not-null key to work. Using a primary key just means it's a unique non-null key.
So, yes you can! You can even reference unique multi-column groups if you need to.
Search for the word "unique" within this page, you'll find further explanations.
Foreign key should necessarily be a candidate key for a table (say table1)? I know that Foreign key references primary key of some other table (say table2). But for the table1, is it necessary that it should be candidate key?
By definition a foreign key is required to reference a candidate key in the target table (table2 in your question). A foreign key does not have to be a candidate key in the referencing table or be part of a candidate key in that table.
No. You can have a 1:N relationship, the FK requirement just says that the field has to exist in the other table. Whether that field is unique or not, does not matter.
For reference:
a candidate key is an alternative to a PK, it can be one field or the combination of fields (as in a concatenated key)
all this establishes is that there is more than one way to uniquely identify a record of the table
a good alternative to an employee_id might be ssn (social security number)
a concatenated key is multiple fields that make up the uniqueness of a record, which can either be an alternative to a PK, or together, act as the PK
because RDBMSs follow at least 1NF, all the fields of the table could be used as the concatentated key
Note: this is a bad choice and only serves as an example
think of an employee_id field as the one PK of the table, but the combination of firstname,lastname, and startdate would probably uniquely identify everyone on your employees table
Note: this is an example, there would probably be better alternatives to this in practice