I have an application that has coaches, clients and workouts.
One coach can have many clients and one client can have many coaches = many to many
One coach can create many workouts and one workout can only be created by one coach = one to many
Also, one client can create many workouts and one workout can only be created by one client = one to many
My problem here is that a workout could only be created by either a coach or a client. Not both. What’s the best way to structure the tables and fields then?
Right now I have a workout that has id: Pk, coachId: Fk, clientId: Fk. But that means that either coachId or clientId are gonna be null on every row. I guess that’s not best practice?
I’ve also thought of just having one user table with a role table connected to it. But I don’t think that’s gonna be optimal/possible since a coach and a client are gonna have many different fields and relations (eg a coach could have certificates and diplomas and a client needs to be able to be assigned to a workout). Also a client need to be able to be assigned to one or many coaches and vice versa.
Current design:
Coach Client Workout CoachClient (composite)
id id id coachId Fk
coachId Fk clientId Fk
clientId Fk
You are on the right path by having two separate FKs (foreign keys) on the table workout.
Now, to make sure only one of the FKs is always null and the other FK is always NOT null you can add a constraint:
create table workout (
id int primary key not null,
coach_id int,
client_id int,
constraint fk1 foreign key (coach_id) references coach (id),
constraint fk2 foreign key (client_id) references client (id),
constraint chk1 check (coach_id is null and client_id is not null
or coach_id is not null and client_id is null)
);
The magic is in the last constraint chk1. It enforces that one and only one of them is not null.
Clients and Coaches are both Persons. So having one table solves your FK problem.
However, if there are a lot of differences in the columns of "clients" and "coaches", then this probably cause more problems than it cures.
Please note that
Foreign Keys have only a small number of properties; you are asking for more than they can give.
A Foreign key implicitly creates an index, to assist with performance; you can build the INDEX without having an FK.
A Foreign key is a 'constraint' that is checked at runtime. Since your complicated check can't be handled by an FK, maybe you should abandon the FK?
I was wondering which of following is better design.
I've got these tables
users
ID | NAME
Categories
ID | NAME
Which one is better, this:
users_to_categories
CAT_ID | USER_ID
In this case CAT_ID and USER_ID are primary keys
or one primary key
users_to_categories
ID | CAT_ID | USER_ID
only ID is primary key
I assume that you are trying to create a many-to-many relationship between the two tables with a third table titled Users_to_Categories. If so, then CAT_ID and USER_ID would be foreign key pointers to the primary keys in Users and Categories.
All that being said, I would refer to the answer given in this thread (SQL - many-to-many table primary key). I agree with the answer given here, saying that there is really no advantage to creating a new auto-increment primary key when the combination of the CAT_ID/USER_ID can serve as a primary key itself.
Altought both designs are fine, I recommend go for one single field for key approach.
It's easier for doing queries.
It's also easier when you want to change some details records from a header o parent table to another, just change the parent foreign key.
say that i have a one to many relations where there are two tables, a Person table and a Belonging table. Now, each Person has ONLY ONE favorite belonging and a specific belonging cannot belong to another person as well.
My question is, where would that information be better kept ? In the Person table as a favorite_belonging_id or in the Belonging table as an is_favorite entry ? To my eyes, the first choice seems to be the better version, but I would like to hear what sql knowledgeable people have to say about it.
EDIT : A Person has many belongings but only ONE favorite belonging and each belonging can only belong to one person. It's a one to many association.
I'd be tempted to go with your first suggestion (a favourite_belonging_id column in the Person table), as one can then create a foreign key reference from (person_id, favourite_belonging_id) to (owner_id, belonging_id) in the Belonging table.
If one were to go the other route of creating a is_favourite flag in the Belonging table, there is no obvious way of ensuring the 1:1 nature of person-favourite belonging relationships (a composite UNIQUE index over (owner_id, is_favourite) would fail when a person has multiple belongings that are not their favourite).
That said, it doesn't feel like this information really belongs in the Person table, as it isn't really a property of the person but rather it's a property of the Belonging. If you feel strongly about it, you could create a Favourites table that has a UNIQUE (or PRIMARY) index over person_id.
to me it does NOT belong in the person table since it has nothing to do with the base person.
if you have only the belonging table - which i also assume has a person_id in it, then this is where you are expressing the relationship between the belonging and the person, and it is where the qualifier should also go.
another option is to have a third table in the middle linking the two - in this case, the favorite flag goes there.
edit:
my preference in design would be the third table option - here you can put a begin date and end date as well as the favorite flag - this would allow you to theoretically trade a belonging to another person at some point in time and still know what happened.
I see that pretty much all the different options have already been laid out in different answers, but instead of commenting on all to give you my impression on what I think you should do, I'll just create an answer myself.
Just to be clear on how I understand how the system works: All users can have multiple belongings, but any belonging can only be help by one person.
In this case, it makes the most sense to have a user_id in the belongings table that can tie a belonging to a person. Once a user_id is set, nobody else can claim it anymore.
Now, as to the 'favorite' part, there are several things you can do. What truly is the best way to do it strongly depends on the queries you plan on running on it. Some consider adding a JOIN table, but honestly this is a lot of additional data that is rather pointless; there is likely going to be the exact amount of rows in it as the user table and by putting it in a separate table, there is a lot you can't do (for example, see how many people DON'T have a favorite). Likewise, a JOIN table would make no sense for the user_belonging relationship, as there is a 1:1 relationship between the belonging and the amount of people who can have it.
So I believe there are two viable options: either add a field (/switch) in the belongings table to indicate of a user's belonging is his/ her favorite, or add a field to the user table to indicate which belonging is the user's favorite. I would personally think that the latter holds the most merit, but depending on the queries you run, it might make more sense to to the former. Overall, the biggest difference is whether you want to process things pre-insert or post-select; e.g. in the latter situation, you will have to run an independent query to figure out if the user already has a favorite (in the former case this won't be necessary as you would put a unique index on the field in the user table), whereas in a post-select situation you will have to do cross reference which of the selected belongings from the belonging table is the user's favorite.
Please let me know if I explained myself clearly, or if you have any further questions.
The following may not be the best options because it offers a somewhat unconventional method of flagging the favourite belonging. The advantage, though, is that this way you'll have just two tables with no circular references and every person will be guaranteed to have no more than one favourite belonging.
So, it's two tables, people (or persons) and belongings. The people table has this structure:
person_id INT AUTO_INCREMENT,
other columns as necessary,
PRIMARY KEY (person_id)
The belongings table is created like this:
belonging_id INT AUTO_INCREMENT,
person_id INT NOT NULL,
is_favourite enum ('1'),
other columns as necessary,
PRIMARY KEY (belonging_id),
FOREIGN KEY (person_id) REFERENCING people (person_id),
UNIQUE (person_id, is_favourite)
The key element is declaring is_favourite as a nullable enum with a single possible value. This way, when you declare a unique constraint on the pair of (person_id, is_favourite), you are allowed to have as many rows with the same person_id and empty (null) is_favourite as possible, because unique constraints ignore rows where at least one member is null. And you won't be able to create more than one person_id with is_favourite = '1', because that would violate the unique constraint.
Neither. My suggestion is to add another table person_favourite_belonging, like this:
CREATE TABLE person
( person_id INTEGER NOT NULL
--- various other columns about Persons
, PRIMARY KEY (person_id)
) ;
CREATE TABLE belonging
( belonging_id INTEGER NOT NULL
, person_id INTEGER NOT NULL
--- various other columns about Belongings
, PRIMARY KEY (belonging_id)
, UNIQUE KEY (person_id, belonging_id) --- this Unique constraint is needed
, FOREIGN KEY (person_id)
REFERENCES person (person_id)
) ;
CREATE TABLE person_favourite_belonging
( person_id INTEGER NOT NULL
, belonging_id INTEGER NOT NULL
, PRIMARY KEY (person_id)
, FOREIGN KEY (person_id, belonging_id) --- for this Foreign Key constraint
REFERENCES belonging (person_id, belonging_id)
) ;
This is just my preferred way of doing this. There are alternatives and all have their pros and cons. The pros with this approach are:
No circular path in the Foreign Key constraints (and therefore):
No chicken and egg problems when inserting, deleting or updating Persons, Belongings or Favourite Belongings.
All foreign key columns can be defined as NOT NULL.
The integrity can be enforced at the database level.
If your requirements change and you want to have 2 (or more) favourites per person, you only change appropriately the constraints at the Favourite table.
Check also my answer in this question (with an almost identical problem): In SQL, is it OK for two tables to refer to each other?
favourite_thing is a FK to the belonging table (if that table exists, otherwise it could be a domain) , but in an additional constraint, you can force belonging_id in the persons table to be unique.
UPDATE:
DROP table belonging;
CREATE table belonging
( id INTEGER PRIMARY KEY
, description varchar
);
DROP table person;
CREATE table person
( id INTEGER PRIMARY KEY
, description varchar
, favourite_thing INTEGER REFERENCES belonging (id)
);
-- Now add the unique constraint
-- NOTE: favourite_thing can still be NULL
ALTER TABLE person
ADD CONSTRAINT must_be_unique UNIQUE (favourite_thing)
;
UPDATE 2: if every belonging belongs to exactly one person, you could add an owner field to belongings:
CREATE table belonging
( id INTEGER PRIMARY KEY
, owner_id INTEGER NOT NULL REFERENCES person(id)
, description varchar
);
DROP table person CASCADE;
CREATE table person
( id INTEGER PRIMARY KEY
, description varchar
, favourite_thing INTEGER REFERENCES belonging (id)
);
ALTER TABLE person
ADD CONSTRAINT must_be_unique UNIQUE (favourite_thing)
;
Actually you present a one-to-one relation.
So you can:
1. Hold it in Person table.
2. Hold it in Belonging table.
3. Hold it in both.
4. Hold it in separate table.
Currently, I am working on the very beginnings of a user database in MySQL InnoDB. So, I will use that to help demonstrate.
Users Roles
--------------- ---------------
userid (bigint) PK >roleid (tinyint) PK
email (varchar) rolename (varchar)
username (varchar)
password (char)
>roleid (tinyint) FK
created (timestamp)
Right now, I am trying to create a one-to-many relationship between Role and Users, based on roleid. For this, I am thinking that On UPDATE CASCADE and On DELETE Restrict.
That's what I feel like I should do, I'm not sure if it's correct or not. However, I'd like to gain a better understanding of it.
Say I wanted to created one-to-one, then that would look like On UPDATE Restrict and On DELETE Restrict, is that correct?
Sorry, I am completely confused here and I am unable to find a tutorial, blog, or explanation that breaks down the different settings to the Relational Model. Could anyone help explain it these types as well as the other types (many-to-many, many-to-one) based on what I have here?
One role can have many users associated to that role. This entire relationship is represented physically with a foreign key on the USERS table that references the ROLES table.
The ON UPDATE and ON DELETE options in the foreign key constraint help to enforce "referential integrity" in the database, but they don't specify at all what the relationship is between the USERS and ROLES entities.
If I create this foreign key with ON DELETE RESTRICT, when I would try to delete a record from the ROLES table where the key was in use on the USERS table, i would get an error. This has nothing to do with the type of logical relationship that exists - it is just a constraint.
A many to many relationship cannot be modeled using one foreign key. Logically, if A user can have Many Roles, storing the role id on the users table doesn't make sense.
In that case, you would create a table in between, and put the userid and roleid columns on this table, with foreign keys connecting them to users and roles respectively.
USERS USERS_ROLES ROLES
userid PK - userid FK
roleid FK - roleid PK
Here's the MYSQL manual pages about foreign key constraints. It's a good reference and explains what each option means.
Edit:
This touched on the one-to-many and many-to-many relationship types. Rarely will you see a one-to-one type in a database (in those cases merging the tables makes sense). Sometimes for performance you would use it. In these cases, typically your primary key should be the same on both tables:
USERS USERS_EXTENDED_ATTRIBUTES
userid PK - userid PK FK
Only 1 user id should exist on each table for a 1-1 relationship.
I have read certain places that it is a good practice to typically use an auto-incrementing Primary key for most MySQL tables, rather than simply relying on a non-increment field that will be enforced to be unique.
My question is specifically about a User table, and a table connected to it by a Foreign Key. Here's the schema:
TABLE Users {
id
name
...
}
TABLE Authors {
user_id (FK)
author_bio
}
Should the Authors table have its own auto-incrementing primary key as well, or should it rely on the user_id foreign key as a primary key?
ALSO
Are there noticeable performance reasons to NOT use the auto-incrementing id as the Primary?
It's not either-or. If you use an auto increment primary key, and you have candidate keys that need to enforce constraints, then your schema should have both.
Both your user and author tables should have individual primary keys. (Every table must have a primary key.) I would not use the foreign key as the primary key. If that truly is the case, I wouldn't have a separate author table; I'd put those columns in the user table.
PS - My naming preference is singular for tables. It should be user and author tables. They happen to contain multiple rows, but a single row means a single entity.
You most definitely want the Authors table to have its own primary key such as authors_id, and then have user_id as a foreign key.
It depends on what you're trying to accomplish. If every author maps to exactly one user (and you're sure this isn't going to change), you can get away with having user_id as a primary key. If not, you'll need an independent primary key for Authors.
(Note that the reverse relation doesn't have to be true: not every user has to map to an author.)