Create one to one relationship in MySQL - mysql

Question

Is this the correct code to link two tables in a way that one-to-one Relationship in MySQL?
Table1
CREATE TABLE employees (id INT PRIMARY KEY AUTO_INCREMENT,FullName VARCHAR(50))
Table2
CREATE TABLE salary (id INT PRIMARY KEY AUTO_INCREMENT,SalaryNumber VARCHAR(6))
ALTER TABLE salary
ADD FOREIGN KEY (id) REFERENCES employees (id)
ON DELETE CASCADE
ON UPDATE CASCADE

Answer 1

Your example has a number of problems, first of which is that you're linking two non-related auto-incrementing ids. This is a nightmare waiting to happen. If anything happens to get those two ids out of sync, you're dead in the water.
In your example, the 'employees' record would be considered the parent record, upon which the 'salary' record is dependent (i.e. - you might have an employee record without a corresponding salary record, but you wouldn't want a salary record that's not associated with an employee).
Foreign key constraints belong in the child table, as stated in the MySql documentation. As such, what you need in the 'salary' table is a column that looks like this:
EmployeeId INT NOT NULL
Your foreign key would be
ALTER TABLE salary
ADD FOREIGN KEY (EmployeeId) REFERENCES employee (id)
ON DELETE CASCADE
ON UPDATE CASCADE
At this point, you still have a many-to-one relationship, as there is nothing to prevent you from inserting multiple entries into the salary table with the same EmployeeId.
To make this relationship one-to-one, you have to create a unique index on the salary.EmployeeId column.
With this type of relationship, it's important to note that:
you are prevented from inserting a row into salary that doesn't have valid EmployeeId
you are prevented from inserting a row into salary that has a duplicate EmployeeId
when you delete a salary record, the employee record remains untouched.
deleting the employee record results in the deletion of the salary record it is referencing (if you don't want this behavior, change ON DELETE CASCADE to something else)
you are prevented from dropping the employee table until the salary table is empty and dropped.

Answer 2

No, that's a one-to-many relationship. You can have any number of salary rows (including none) linking to a single employee row.
Since the salary is very much an attribute dependent on the employee, I would consider placing it in the employee table itself (unless you have some extra knowledge you haven't shared with us which makes this problematic).
There are ways to enforce one-to-one across separate tables.
For example, you can use triggers to stop duplicates, though some people are adverse to triggers, and this still won't prevent one-to-zero mappings from appearing.
Alternatively, you can use bidirectional foreign keys with a dummy row in both tables (pointing to each other) to allow you to insert in one table at a time.
The way this is done is to insert a row in employees pointing to the dummy salary row.
Then insert the salary row pointing to the newly inserted employee.
Then update the employee row to pint to the newly inserted salary row. All this should happen as a single transaction of course, to maintain referential integrity at the application level.
In order to get the dummy rows in, they'll need to be inserted before the foreign key constraints are added to the schema, otherwise you have a chicken-and-egg situation.
Whether that level of work is actually necessary is debatable, especially when you can enforce one-to-one simply by combining the data into a single table as suggested :-)