I'm having trouble wrapping my head around how to set this up. I have two tables:
Projects
Sections
1 project can belong to many sections.
1 section can have many projects.
How would I go about setting this up, would this be a many to many relationship or one to many?
Would it best if I created a lookup table?
would this be a many to many relationship or one to many?
It's regarded as many-to-many, because many projects can refer to many sections.
You'll need to implement a table that sits between projects and sections, using foreign keys from both to be the primary key. Example:
PROJECTS_SECTIONS_XREF table
PROJECT_ID, pk, fk
SECTION_ID, pk, fk
The naming convention is up to you, but I recommend something informational by using the names of both tables involved. Corrollary, cross references (xref), lookup, etc. There's been two questions regarding the naming convention in the past week or so - all the names are synonyms, choose whatever you like.
This is a simple 1-to-many relationship . The 2 requirements you stated above amount to the same thing. No lookup table is required. In your sections table you simply have a fk back to the projects table
Create a relationship table... let's call it ProjectSections, with fields ProjectId and SectionId. You create the relationship between a project and a section in ProjectSections by creating a record with the ProjectId and the SectionId.
ProjectSections then links the Projects and Sections together.
Related
I'm trying to design my database with very basic tables and I am confused on the CORRECT way to do it.
I've attached a picture of the main info, and I'm not quite sure how to link them. Meaning what should be a foreign key, or should some of these tables include of LIST<> of the other tables.
UPDATE TO TABLES
As per your requirements, You are right about the associative table
Client can have multiple accounts And Accounts can have multiple clients
Then, Many (Client) to Many (Account)
So, Create an associate table to break the many to many relationship first. Then join it that way
Account can have only one Manager
Which means One(Manager) to Many(Accounts)
So, add an attribute called ManagerID in Accounts
Account can have many traedetail
Which means One(Accounts) to Many(TradeDetails)
So, add an attribute called AccountID in TradeDetails
Depends on whether you are looking to have a normalized database or some other type of design paradigm. I recommend doing some reading on the concepts of database normalization and referential integrity.
What I would do is make tables that have a 1 to 1 relationship such as account/manager into a single table (unless you can think of a really good reason not to). Add Clientid as a foreign key to Account. Add AccountID as a foreign key to TradeDetail. You are basically setting up everything as 1 to many relationships where the table that has 1 record for the id has the field as a primary key and the table that has many has it as a foreign key.
Are there any hard and fast rules against creating a junction table out of a table's primary key? Say I have a table with a structure similar to:
In this instance there are a list of items that can be sold together, but should be marked as dangerous. Any one item can have multiple other items with which it is dangerous. All of the items are uniquely identified using their itemId. Is it OK to refer a table to itself in a many-to-many relationship? I've seen other examples on SO, but they weren't SQL specific really.
This is the correct design for your problem, as long as your combinations can only be two-item combos.
In database design a conceptual design that renders a relation in many-to-many form is converted into 2 one-to-many in physical design. Say for example a Student could take one or many courses and a course could have many students, so that's many to many. So, in actual design it would be a Student table, Course table then CourseTaken table that has both the primary key of Student and Course table thus creating 2 one to many relayionship. In your case altough the two tables are one and the same but you have the virtual third table to facilitate the 2 one to many relationship so that to me is still very viable approach.
I'd like to hear opinions on if it is better to keep forum categories and subcategories in the same table or in two separate tables...
Let's say you have a table ForumCategories. By adding a colum ParentId referencing the PK Id in the same table you could easily keep both the main categories and subcategories in the same table.
Alternatively, you could create a separate table ForumSubCategories and make the Id on that table a FK referencing PK Id column of the ForumCategories table.
Both solutions would work but what are the pros and cons of each solution?
Obviously, this is a more generic question that can apply to many other scenarios I just couldn't come up with a better phrasing in a hurry...
I can't think of any benefits of using 2 tables. Using 2 tables is going to constrain you to a 2 level tree. If you look at things as objects, then subcategories really are just category object. So put them in the same table. The 1 table structure will be simpler to design around and develop queries for.
If you know for sure that your forums will have only 2 levels of categories, then having 2 tables is reasonable.
Though storing categories in one table with foreign key to itself, basically, allows you store a tree of categories with virutally unlimited levels.
If they are the same entity (Category), you can link to itself. The parent would have a null for the parent ID or it could be linked to itself. This limits you to only one level unless you have a second table to handle the many-to-many possible relationships.
They must have the same fields or you're going to have unecessary fields for one or the other type. A separate table is why you would do this because they're not the same.
This is typical for an employee table. The supervisor is another employee record.
I have a trip (primary: idTrip), where I can link more packages (primary: idPackage), so, I got a relationship table to link trips with packages (primary: idRelTripPackage). (relationship n-to-n)
And next I got a registrations table (primary: idRegistration). How do I best link those (1-to-1 relationship)?
I add two columns in the registrations table (idTrip, idPackage)?
I add a relationship table where i link idRegistration, idTrip, idPackage?
I add a relationship table where i link idRegistration, idRelTripPackage?
Am I right in thinking the relation from Registrations is to RelTripPackage, and its definitely one-to-one. There are a couple of options:
1: As it really is a one-to-one there's not really anything to stop you putting the Registrations data directly onto RelTripPackage, or doing the vice-versa and putting idPackage and idTrip straight onto Registrations as FKs, with a unique key across the two FK columns to ensure there aren't duplicates.
2: If do want the two separate tables then just add idRetTripPackage to Registrations as an FK, and then add a unique constraint on it - again to ensure uniqueness.
There's no need for a separate relationship table as its a 1-1 relationship - They only really become relevant when you are using an n-n. The rest of the time FKs should be placed directly on the child table.
If you follow that logic, you will
add tables and Relations every time you need to add Relations
end up with confusing or duplicate Relations (multiple paths between any two tables)
However the problem (limiting factor) is that the tables you are starting with are not actually normalised. Since the starting position does not have a good basis, you will end up with far more Relations (in tables) than there actually are between the Entities. So the best advice is, the Best practice is, before you attempt this current extension, step back and normalise the data, the existing tables. Then the extension will be much easier, and you will end up with less tables.
if you provide info re the tables (Person, Trip, Package, etc); what exactly is a Registration, etc ... I can provide more explicit answers.
Generally any attribute that is 1::1 with the PK of an Entity should be an attribute in that entity. Any attribute that is 1::0-1 with the PK of an Entity should be in a separate table.
ER Diagram
Based on the information provided, this is your ▶Entity Relation Diagram◀. As long as you use Relational Identifiers, all the Relations you have identified thus far are supported directly (otherwise, if you use IDs, you will need more Relations and tables).
Readers who are unfamiliar with the Relational Database Modelling standard may find ▶IDEF1X Notation◀ useful.
I know, there is a lot of info on mysql out there. But I was not really able to find an answer to this specific and actually simple question:
Let's say I have two tables:
USERS
(with many fields, e.g. name, street, email, etc.) and
GROUPS
(also with many fields)
The relation is (I guess?) 1:n, that is ONE user can be a member of MANY groups.
What I dis, is create another table, named USERS_GROUPS_REL. This table has only two fields:
us_id (unique key of table USERS) and
gr_id (unique key of table GROUPS)
In PHP I do a query with join.
Is this "best practice" or is there a better way?
Thankful for any hint!
Hi all,
thanks for your quick and helpful support. Knowing that I was on the right way builds up my mysql-self-confidence a little. :-)
As many commented, my example is not 1:n but many to many. Just as a quick sql-lesson: :-)
Are these the right terms?
1:n one to many
n:1 many to one
n:n many to many?
You have described a many-to-many relationship. Using that relationship, many USERs can be members of many GROUPS. For your purposes, this is indeed the correct way to go.
One-to-many and one-to-one relationships do not require the link or cross-reference table (USERS_GROUPS_REL).
You might find this tutorial useful:
http://www.tonymarston.net/php-mysql/many-to-many.html
It's quite the best case :)
Creating a compound predicate primary key in the relation table is the optimal solution:
ALTER TABLE USERS_GROUPS_REL ADD PRIMARY KEY(us_id, gr_id)
That would be the best practice.
You have two tables on either side of the join and a mapping table (or linker table, or whatever other terminology is out there) in the middle which handles the Many-to-Many relationship (A Group has many Users and a User can belong to many Groups).
To increase performance, you should make a composite key for the mapping table out of us_id and gr_id. You can also create an index on the inverse so that if you need to sort by gr_id, you get the performance benefit there too.
One user can belong to many groups, and one group contains many users, so it is a many-to-many relationship.
The way you describe it is a typical and correct one. A many-to-many relationship is often mapped with an association class or relation table.
Sometimes the relation table has more columns. For example, a user may be the administrator of a particular group. The users_group_rel table would then also have a field administrator.