I am developing my tables for a website that I am working on, and after not doing much SQL in the past couple of years, I am a little bit rusty. I understand the concept of normalization and such, but this is a little bit confusing:
I have a few sections in the website where contacts will be listed, primarily on an Events page and on the website's Contact page. I would have a relation table that would be something like (just as an example) eventlisting hasmany contacts, which is fine because at least I could have a number of contacts attached to an event listing.
Would it be fine to have a table that just has a foreign key that points to my primary contacts table, and use that for listing my primary contacts?
Generally in a one-to-many relationship, it's the "many" that contains the FK. That way many event listings can be mapped to the same contact listing.
So in your case, the contacts table would have a FK to your eventlisting table.
If for some reason you need to have a many-to-many relationship, you'd want to create a join table that both your eventlisting and contacts table would have FKs to.
If an event can only have one primary contact, you can do it in two ways:
Add a primary_contact_id column in the Events table, as a FK to the Contacts table.
Use a relation table Event_Primary_Contacts, containing two FK's: Event_id and Contact_id. These should be a unique key in the table.
You could also add a boolean Primary column to the Event_Contacts table. However, this doesn't allow the DB to implement the constraint that there can be only one primary contact for each event.
Related
I'm creating a database for personnel records and trying to ease record creation for the user and avoid a kludgy solution. The tables are:
people:
people_id,
person_name,
person_category_id
person_category:
person_category_id,
person type
document_requirement:
document_requirement_id,
document_requirement_name,
person_category_id,
document_section_id
document_section:
document_section_id,
document_section
I've created an append query (inner join) that populates a table caLLed document_repository which contains all of the required documents for all of the people. (I use a primary key composed of people_ID & document_id to avoid duplicates when the append query runs.) Here is the document_repository table.
document_respository:
document_repository_id,
people_id,
person category_id,
document_id,
document_section_id,
document_attachment
I'd like to be able to allow the user to create a document requirement that is applicable to multiple person categories. I understand I should avoid multi field values, which doesn't work anyway with inner joins. For example, if people categories include doctors and nurses, I'd like to be able to create a new document requirement that applies to both people categories (e.g., doctors and nurses), without having to create two separate document requirements.
More information needed?
Suggestions on design changes and/or queries?
Thanks!
snapshot of tables and relationships
What you describe is a many to many relationship. Each document requirement can be applicable to multiple person categories and different document requirements can be applicable to the same person category.
To have a many to many relationship between two entities (tables) in your database, you need another table to relate them. This additional table contains the primary key of both tables and each record in this table represents a link between the two entities.
Your naming is different between your text and your diagram, but I'll assume you want to have document_requirement records that can link to zero or more person_category records.
You need a table which for example could be called document_requirement_person_category and contains the following fields:
document_requirement_id - foreign key referencing PK of document_requirement
person_category_id - foreign key referencing PK of person_category
You then add a record to this link table for each person category that relates to each document requirement.
Edit: BTW, (if I'm reading your schema correctly), you already have a many to many relationship in your schema: document_repository allows a relationship between multiple people and a document requirement as well as multiple document requirements and a person. That's a many to many relationship.
I'm using MySQL and have been planning out the database structure for a system I'm building out. As I've been going along, I started to wonder if it was acceptable to have a particular foreign key constraint in many different tables. From what I understand, it would be fine, as it makes sense. But I'd like to double check.
For example, I have a users table, and I use the user_id as a foreign key for many tables, sometimes multiple times in one table. For example, I have a one-to-one relationship with a user_settings table, which of course stores the user_id. And then I have a companies table, which alone has a few references to the user_id key. In this case, I have a column that keeps track of the user that created the company in the system (created_by), a column for the main contact (main_contact, who is also a user of the system), and there might be another reference. So that alone, already has the user_id key being used as a foreign key constraint 3-4 times.
Just to add another bit of info, I have a tasks table and that of course needs to reference the user_id to keep track of who it's assigned to, and I also have another column that keeps track of the user that created the task. That would be assigned_to and created_by, respectively.
There are more tables though that reference back to that key. I might be up to 8 references already. I do believe I've designed it properly so far, but based on what I've mentioned, does this sound fine?
Your foreign key usage seems fine to me - after all, you are simply representing logical relationships between your tables.
A user within your system interacts with the data in many ways, and to define these relationships your approach is the correct one.
The key point I think is that under a lot circumstances, you won't always want (or need) to make all the joins that represent your relationships - simply the ones that you need in that context.
As per my undestanding the way you are defining is fine i.e to use a user id to many tables as foreign key.
If your line:: I have a companies table, which alone has a few references to the user_id key doesn't mean that you are using multipe user_id in same table and I know you are not.
I have a table called 'notes', on this table I need to track who made that note, but the problem is that the creator of the note can be a user stored in one of three possible tables:
users
leads
managers
I have though of simply create three fields on 'notes' to represent the three possible relations: note.user, note.lead, note.manager
With this approach I would be forced to create three table joins when requesting the notes to gather the creators information, and I don't think that is the way to go, so I would like to hear your ideas or comments and what would be the best approach on this.
For me personally this smells like a design problem on a totally different part of the schema: Are manageers not users? Do leads carry person information?
With any approach that creates a relation between one column and one of three others, you will need three joins for the select. If you can't rectify the underlying problem, I recommend you use
note_type ENUM('users','leads','managers')
as an additional field and
SELECT
...
IFNULL(users.name(IFNULL(managers.name,leads.name))) AS name
..
FROM notes
LEFT JOIN users ON notes.note_type='users' AND users.id=notes.note_source
LEFT JOIN managers ON notes.note_type='managers' AND managers.id=notes.note_source
LEFT JOIN leads ON notes.note_type='leads' AND leads.id=notes.note_source
...
for the query
I think you need to abstract out the concept of a user id, so that it does not depend on their role. The author of a note could then be specified by the user id.
Users could be assigned roles, and maybe more than one.
The correct way to structure this would be to pull all common data out of users, leads, and managers. Unify this data into a "contact" table. Then if you want to get all notes for a given manager:
managers->contacts->notes
for a lead:
leads->contacts->notes
Notice your original post: "the problem is that the creator of the note can be a user stored in one of three possible tables"
From the structure of your sentence you even admit that all these entities have something in common; they are all users. Why not make the DB reflect this?
you have to model a parent table for the three tables you already have. Define a table that depicts generally user, leads and manager tables. Something like "Person". So you have all of the ids of the three tables and any common attributes on the Person table. And when you must define the relationship you put the foreign id "Person_ID" on the note table. And when you model user, leads and manager tables you also put the primary key as a foreign key to the Person table.
So you would have something like this:
Table users:
Users(
person_id primary key
...(attributes of Users)
foreign key person_id references Person.person_id
)
This model i depict is common to any relational model you have to model using parents and childs
Suppose that I have a table users, with a PK id_user.
I also have an identifying relationship between the table users and the table employer. I can use the PK id_user as foreign key in the table employer and also as PK (with unique constrain) in this table?
In this case, the employer only have a worker and a worker only have an employer.
Short answer: Yes. When a foreign key is also the primary key of the child table it forces it into a one-to-one.
Longer answer: in my experience every 1-to-1 I've every made has been expanded later into a 1-to-many or many-to-many, as the users' requirements are better understood. Example: You end up needing a history of employers, so suddenly you have a many-to-many from persons to employers with effective dates.
After this happened a few times I made it a point to dig into the reasons why a 1-to-1 seemed to make sense, and always found it did not. So much so that I made a rule of thumb for myself to avoid 1-to-1 tables, as they usually indicate an incomplete understanding of requirements.
Primary keys are special unique keys. In this case I would not link worker in the employers table as typically an employer has more then one worker. If you're absolutely sure it is a one-one relation, I do not see why you use 2 tables, instead of one. Meaning, add the employer fields to the worker table. A real one-one relation is for example a phone number or email address and typically they are stored with the owner, not in a seperate table.
I have a parent table called 'Website' which holds records about websites. I have a child table called 'SupportSystem' which holds records about different types of support systems such as email, phone, ticketing, live chat etc. There is an intermediate table 'Website_SupportSystem' which joins these tables in a many-many relationship.
If the SupportSystem for a Website is ticketing, I also want to record the software platform .e.g. WHMCS. My instinct is to create a new lookup table called SupportPlatform and relate this to the existing join table 'Website_SupportSystem' and store the data there. However, then there is no relationship between the SupportSystem and SupportPlatform. If I relate those then I end up with a circular reference.
Can you see what I am doing wrong? What would be the best way to model this data?
You could use super-type/subtype relationship, as shown in the diagram.
SupportSystem table contains columns common to all support systems.
Email, Ticketing, Phone and LiveChat tables have columns specific to each one.
Primary key in the subtype table is also a foreign key to the super-type table.
I would add a new column 'SupportPlatformId" to the "SupportSystem" table which lookup to the table "SupportPlatform", because "SupportSystem" to "SupportPlatform" is probably one-to-one or many-to-one.
Hence: Website -> (via Website_SupportSystem) SupportSystem -> SupportPlatform
Data about a Support Platform should be stored in the SupportPlatform table.
You can add a third foreign key, namely SupportPlatfromID, to the Website_SupportSystem table. If you do this, your intermediate table now records a ternary relationship, of the kind many-to-many-to-many. If this reflects the reality, then so be it.
If you want to relate SupportSystems and SupportPlatforms, just use the intermediate table as an intermediate table in the joins. You can even do a three way join to join all three entities via the intermediate table.
An alternative would be to create another intermediate table, SupportPlatform_SupportSystem, with a pair of foreign keys, namely SupportSystemID and SupportPlatformID. If this reflects the reality better, so be it. Then you can join it all together with a five table join, if needs be.