I'm not quite sure how to word this so I've not managed to find an answer for it!
I want to create a table, where in certain columns there is multiple rows. As shown in the picture
How do I structure this?
An example of what I'm trying to achieve is imagine a table that listed all users in an application. Each row is a user, but I want to also have a sub row for each of the photos that a user may have.
You cannot have multi-valued columns. As they do not satisfy first normal form (For detailed information about 1st Normal form: https://en.wikipedia.org/wiki/First_normal_form)
Let your table have the following columns:
(A,B,C,D)
As per the picture provided by you, I am making the following assumptions:
1) A is the primary key
2) C and D are both are multi-valued and the rows have values like (A1,B1,C1,D1),(A1,B1,C2,D2). That is for single A value we have multiple pairs of C and D.
Do comment if any of the assumption is wrong.
What you can do is make two tables.
TABLE1 (A,B)
TABLE2 (A,C,D)
Where A is the primary key in TABLE1 and foreign key in TABLE2.
As asked for a snippet,you can have tables like these:
Tables
Related
In MS-Access, I've got a table where its key input is either a primary key of one type (of companies) or the primary key of another type (of companies). There's virtually no overlap in fields between these two types (hence they're separate tables).
How does one structure this as links etc just relate to one table?
Thank you
Use a union query. The official guide is here:
Use a union query to combine multiple queries into a single result
I have a table which contains id and supervisorId. Id is the PK and supervisorId is the foreign key (Self Join).
When I try to insert the data into the table, mysql throws unable to add or update a child row error. Because of relationship between two columns, I can't populate the supervisorId column without Id column.
Is there any way to insert the data in a single query?
You need to insert the rows in two steps:
Insert the rows without supervisors (i.e. supervisor_id = NULL.
Then update the rows with the correct supervisor, when you know their ids.
It is not clear how you are processing the data. If you are trying to move rows from one table to another, you should probably ask another question, with sample data, desired results, and a clear explanation of what you want to accomplish.
For example, I have a table positions in which I would like to create a relationship between multiple table rows. If the number of rows that need to be "linked" together is unknown, what makes the most sense with a separate table to link the ids?
Is it best to...
Create a separate table links with many columns (ie: linked_id1 [...] linked_id[n]) where the linked_ids are the id of each row and the links.id column is the id of the link. The logic is that we can create more columns than we think we will need.
OR
Create a separate table links with two columns, id and linked_ids where linked_ids is a comma separated array of the "linked" rows from positions.
OR
Do the aforementioned replacing the array with JSON data.
Each row can only be linked into one group, which hopefully simplifies things.
If each row can be included into multiple linked groups then you can create LINKS table with two fields: ID1, ID2 that will store each individual link.
If each row can be only in a single linked group then you can add GROUP_ID field to the positions table itself.
If the above does not answer your question, please clarify your requirements.
I have 2 tables.
First table is called professions, and those are indexed by ID. So each profession now has a unique ID associated with it.
My second table is called contacts, and in there I have a profession field that right now only hold the ID that a certain profession is associated with.
My problem is that what if I have a contact that has more than one profession associated with it.
What would be the best way to query the table and ways to store the professions of a contact. I didn't want to do is create a field to just store a 0 or 1 int for each profession I have. The reason is because I want to dynamically grow the professions table and have the numbers reflect any dynamic changes on my site when I query.
You have a many-to-many relationship. To implement that in MySQL you should use a linking table. So professions and contacts should have an id in each table, but no foreign keys, and you create a new table called profession_contact_links or something, containing its own id, and profession_id and contact_id, which are both foreign keys to the respective tables. Then you can have many contacts linked with each profession, and many professions linked with each contact. To connect the two main tables together in a select you will need two joins, and what they are will depend on what exactly you want to select.
The standard solution to this modelling issue is called a link table.
Basically it is a table that contains the ids of the two tables that are linked, so you would have a link table with to columns and a primary key that is both of those columns:
(profession_id, contact_id)
or the other order... doesn't matter that much, but the order can affect performance, the key you will be searching on most often is the one you want first.
You then use either SELECT ... IN (...) or SELECT ... JOIN ... to query the data that you are after.
Depending on what you want and how you want to find it, i'd suggest rlike or in
SELECT ... FROM <table> WHERE <column name> RLIKE "^id1|id2|id3$"
This will find any cell that contains any of those three terms
or use
SELECT ... FROM <table> Where <column name> IN ('id1','id2','id3')
this will find any cell that is equals to one of those three.
Been reading the tutorial How to handle a Many-to-Many relationship with PHP and MySQL .
In this question I refer to the "Database schema" section which states the following rules:
This new table must be constructed to
allow the following:
* It must have a column which links back to table 'A'.
* It must have a column which links back to table 'B'.
* It must allow no more than one row to exist for any combination of rows from table 'A' and table 'B'.
* It must have a primary key.
Now it's crystal clear so far.
The only problem I'm having is with the 3rd rule ("It must allow no more than one row to exist for any combination").
I want this to be applied as well, but it doesn't seem to work this way.
On my test instance of mysql (5.XX) I'm able to add two rows which reflect the same relationship!
For example, if I make this relation (by adding a row):
A to B
It also allows me to make this relation as well:
B to A
So the question is two questions actually:
1) How do I enfore the 3rd rule which will not allow to do the above? Have only one unique relation regardless of the combination.
2) When I'll want to search for all the relations of 'A', how would the SQL query look like?
Note #1: Basically my final goal is to create a "friendship" system, and as far as I understand the solution is a many-to-many table. Suggest otherwise if possible.
Note #2: The users table is on a different database from the relations (call it friendships) table. Therefore I cannot use foreign keys.
For the first question:
Create a unique constraint on both
columns
Make sure you always sort the columns. So if your table has the
colummns a and b than make sure
that a is less than or equal to
b
For the second question:
SELECT
*
FROM
many_to_many_table
WHERE
a = A or b = A
It sounds like you want a composite primary key.
CREATE TABLE relationship (
A_id INTEGER UNSIGNED NOT NULL,
B_id INTEGER UNSIGNED NOT NULL,
PRIMARY KEY (A_id, B_id)
);
This is how you setup a table so that there can only ever be one row that defines tables A and B as related. It works because a primary key has to be unique in a table so therefore the database will allow only one row with any specific pair of values. You can create composite keys that aren't a primary key and they don't have to be unique (but you can create a unique non-primary key, composite or not), but your specification requested a primary key, so that's what I suggested.
You can, of course, add other columns to store information about this specific relationship.
Ok WoLpH was faster, I basically agree (note that you have to create a single constraint on both columns at the same time!). And just to explain why you collide with the rules you mentioned: Typically, A and B are different tables. So the typical example for n:m relations would allow entries (1,0) and (0,1) because they'd be refering to different pairs. Having table A=table B is a different situation (you use A and B as users, but in the example they're tables).