I have two tables named business and business_category that have many-to-many relation. What name should I use for a third table that bind them together? I don't like business_business_category name at all.
You could name it - BusinessCategoryLink or BusinessesPerCategory
I would like to suggest you. Can make three table. Business, categories, businesses_x_categories. All business are will be in business table , all categories will be categories table and both table link will be business_x_categories.
Multible. Business have same categories. So we can link with same category and different business.
Related
I am learning sql now and practicing the scenarios to design the tables. I have a one scenario where I could not find proper suitable table structure.
The scenarios is as follows, I want to store depedencies user journey in sql. For example, in customer creation journey, we need to create valid sector, language and country codes in the system. Another example, to create a new account (bank account), we need to create the sector, language and country followed by customer.
So far, I could think of following table design, but I am sure this is not good as there is no primary key and not following the normalization standards.
journey
dependent
order
CUSTOMER
SECTOR
0
CUSTOMER
LANGUAGE
1
CUSTOMER
COUNTRY
2
ACCOUNT
CUSTOMER
0
I understand that this is many to many relationship as one journey can have many dependent and one dependent can be associated with multiple journeys. I need help to efficiently design the tables in sql, please can anyone help on this.
You need from the intermediate/join table that should look like this -
Table name - journey_dependent
Coll(Jurney_FK) Coll(Dependent_FK)
journey_id dependent_id
You can check more here - https://www.baeldung.com/jpa-many-to-many#1-modeling-a-many-to-many-relationship
If journey and dependent values are PK in origin tables, you have 2 FK. You can create a composite PK on that table with that 2 columns.
Maybe order need to be in dependent table. If not, there is information on that table : order. So this is not a pur relationship table. So you could optionally had a technical PK column (auto increment) on it.
How can I insert many values into one database field?
Is it possible?
I want to make a table for meetings, and invite many persons. So how can I add persons to my meeting table?
You have to choose a many-to-many design. One person can go to many meetings, and many people can go to one meeting.
Meetings table:
- MeetingId (int)
- Date (DateTime)
People table:
- PersonId (int)
- Name (char)
PeopleInMeeting table:
- MeetingId (int)
- PersonId (char)
This way you can book many people in you meeting (with many records in PeopleInMeeting), o one person can book in many meetings (same way)
Entity
In a relational database each table stores a single type of record as row (e.g. a single Meeting, or a single Person, or a single MeetingAttendance). Each record (row) in a table has some columns, a primary-key (e.g. ID) plus different attributes (e.g. name, date, location). This concept is called entity.
Relationship
Since for each type of record there is one table, you can now model the relationships between these records/tables using foreign-keys if its one-to-one (1:1) or one-to-many (1:n). In your case a single person can visit/attend many meeting's and a single meeting can be visited by many persons. So the relationship, lets name it MeetingAttendance, is many-to-many (n:m). This n:m relationship is best modeled using a so called association-table, which stores both foreign-keys.
See similar question Relationships for “Meetings” List.
Entity-Relationship (ER)
An ER-model or ER-diagram depicts these relationships between entities.
So your ER-model will look like this:
The database has a table called "categories" with columns CATEGORY_ID(primary key) and CATEGORY_NAME.
I have subcategories for each category.
For better accessing which is the best method from the below methods.
Method 1: The "CATEGORY_ID" column in the "categories" table is a FOREIGN KEY in the "subcategories " table.
Method 2: Maintaining a separate table for each category representing the subcategories.
I prefer to use same table for category and sub category
like
Table Categories
[CATEGORY_ID, CATEGORY_NAME, PARENT_CATEGORY_ID]
In case you don't know how many sub categories are there.
This scenario is just an example, the scenario is as follows: We have a product table where all the records of products are stored. Same way we will have customer table where records of customers are stored. The daily sales keep the record of all the sales. This sales table will keep record of which product who has purchased. So linking is to be done from Sales table to product table and customer table.
The query to link the two tables is as follows:SELECT product_name, customer.name, date_of_sale FROM sales, product, customer WHERE product.product_id = sales.product_id and customer.customer_id >= sales.customer_id LIMIT 0, 30
It is better to go with Method 1 since it is more scalable.
Let me elaborate on this. If we go with method 1, we need to maintain 2 tables only that is Categories and Subcategories. In future if we have new categories or subcategories we can directly deal with this 2 tables.
If we consider same situation with Method2 then we need to create new tables every time, this may become maintenance overhead.
Let me be a bit more direct. You explain in a comment that Method 2 is a separate table for each category. If so, then Method 2 -- in general -- is just wrong.
There are two methods for storing this type of information. One is a Categories table with a (single) Subcategories table. The Subcategories table would have CategoryId, a foreign key reference back to Categories. This is the normalized data model.
The second method is to store everything in one table. Each row would be a category/subcategory combination. Information about a given category would be duplicated across multiple rows, so this is not a normalized approach. However, this is a typical approach when doing dimensional modeling for decision support systems.
If the subcategories are just names of things, there is a third approach, which would be to store a list of the subcategories within each Category row. The list would not be a delimited string. It would be JSON, a nested table, XML, array, or similar collection data type supported by the database you are using. I am mentioning this as a possibility, but not recommending it.
I am making a quiz-program. In a quiz I have many participants, but on the other hand participants can enter many quizzes (over time). So I have overcome this many-to-many relationship with a linking table. So far I can understand.. now for the difficulty for me: a participant can either be a group, or a single player.
So a quiz has a participant (with a linking table) and this participant is either a group which has several persons, or this participant is a player and only one single person.
table Quiz : PrimaryKey = quiz_id, (name, date,... )
table QuizParticipant : PrimaryKey = quiz_participant_id, quiz_id
table ParticipantGroup : PrimaryKey = quiz_participant_id, group_id
table participantPlayer : PrimaryKey = quiz_participant_id, person_id
The problem for me is: how do I query all participants of a quiz by quiz_id, and preferably sort them by type (group or player)?
Tips on how to google this stuff are usefull as well :)
It's an interesting design decision. The way you proceed can shape your entire application.
My advice is to record the participant type within each occurance of participation. This would be either "GROUP" or "PLAYER" and would define whether the ParticipantID referred to a GroupID or a PlayerID. This will result in the cleanest database design and application logic in the end.
So your tables look like:
Quiz (QuizID,QuizName)
QuizParticipation (ParticipationID, ParticipantType, ParticipantID)
Group (GroupID,GroupName)
GroupMembers(GroupID,PlayerID)
Player(PlayerID,Name)
You might need to make a custom constraint to ensure that duplicates cannot be created within the ParticipantID and ParticipationType combined fields of the QuizParticipation table, or manage the generation of primary keys carefully.
My suggestion is to always link your quizzes to groups (many to many) and treat single players as a group of 1. So your groups are linked to players (also many to many)
If a person can belong to many groups and a group can have many people, that's another many to many relationship. Since you know how to create these linking tables, create one for this relationship.
I'm dealing with this situation. I've got three tables in SQL SERVER called Movies, Series and Orders.
Orders has an ItemId where this could be a MovieId (Movies PK) or SerieId (Series PK). I mean, in Orders table could have records where are from movies of series.
I don't know how to maintain this relationship or which could be the best way to implement it. Until I know, I only can create 1 to 1 or 1 to many relationships between 2 tables, not for 3.
Thanks in advance.
In this case I think it would be better to store Movies and Series in the same table with the common attributes incl. a column which indicates the type (Movie or Serie) and then have the additional attributes in seperate tables (if you want to normalize) or even in the same table (in order to avoid joins).
You should learn about implement table inheritance in sql-server.
Do you have a product and this product may be a Movie or a Serie.
In linked sample a person may be a student or a teacher.
The best way is:
create a generic table for movies and series with the fields that both entities should share (like ItemId).
create a table for movies that references the table created on step 1, containing the fields that must be compiled only for movies. This new table will be in relation one-to-one with the previous one.
same thing for series.
create the orders table and set ItemId foreign key to point to the ItemId primary key of the table created on step 1.