Связать 3 таблицы mysql

Обновлено: 27.04.2024

Добрый вечер.
Есть задача переписать движок сайта. Начал с приведения БД в порядок.
Но вот в чём проблема (самостоятельно додумать не в состоянии).
Есть три таблицы:
1) Туры
2) Туристы
3) Инструкторы
В этих таблицах несвязанные между собой данные, поэтому, id(PK) в этих таблицах повторяются.
Для каждой из записей в этих таблицах можно прикреплять изображения, изображений может быть много.
В старом варианте, для каждой таблицы есть дочерняя, специально для изображений. Таблицы для изображений совершенно одинаковые, количество полей, названия полей, типы данных, размеры данных и т.д. и т.п. Совершенно одинаковые три таблицы, только названия разные у них.
Поэтому я подумал, что это слишком, три одинаковые таблицы и решил все изображения(пути к файлам) хранить в одной таблице.
Вообще-то проблем с реализацией особо не возникает. Можно через внешний ключ, можно связующую таблицу. Но на этом этапе зашёл в тупик.
Если я возьму первую таблицу, "туры", и все изображения для этих записей перенесу в новую таблицу, то проблем нет.
Но если переносить изображения для "туристы" - возникает проблема. Для того, чтобы связать по внешнему ключу надо в таблице изображений завести колонку "parend_id", но у "туров" и "туристов" есть одинаковые id(PK) и поэтому не получается слить изображения в одну таблицу.
Думал и про связующую таблицу, но и там нужна колонка "parent_id" и опять совпадения.

Как можно решить данную проблему? Подскажите, пожалуйста, кто уже сталкивался с подобным.

P.S. Из таблицы "Туры" идут связи через внешний ключ на другие таблицы, не только на изображения.

P.S.S Или сделать в таблице изображений три поля для связующих id - tour_id, instructor_id and tourist_id?
Но не слишком ли это будет?

Это я и хочу сделать, но id в таблицах c турами, туристами и инструкторами совпадают.
Данные со старого сайта и к турам, например, привязаны цены, а к туристам их заказы.

slo_nik: Именно. Такая схема позволит сделать связь многие-ко-многим, то есть использовать несколько фотографий для одного тура/туриста/инструктора и использовать одну и ту же фотографию для разных туров/туристов/инструкторов.

Rsa97: Хотел сократить количество одинаковых таблиц, но видать никак не обойти это)))
Ну что же, так и буду делать.
С внешним придётся повозиться, ну да ладно)

Добавить в избранное

Главное меню » Базы данных » Учебное пособие по SQL » Как присоединить три таблицы в SQL запросе – Пример в MySQL

О бъединение трех таблиц в одном запросе SQL может быть очень сложно, если вы не очень хорошо понимаете объединение в SQL. Объединения SQL всегда были сложным не только для новых программистов, но и для профессионалов, которые уже долго занимаются программированием и используют SQL более чем 2 -х до 3 -х лет. Есть достаточно причин, чтобы запутаться в SQL JOIN, начиная от различных типов SQL JOIN like INNER и OUTER join, LEFT и RIGHT outer join, CROSS join и т.д. Между всеми этими основами, наиболее важным является регистрация, объединения нескольких таблиц. Если вам нужны данные из нескольких таблиц в одном запросе SELECT, вам нужно использовать либо подзапрос либо JOIN. Большую часть времени мы только соединяем две таблицы, как Employee и Department, но иногда вам может потребоваться присоединение более двух таблиц и наиболее частый случай – объединения трех таблиц в SQL.

В случае присоединения трех таблиц, первая относится к таблице 2, а затем таблица 2 относится к таблице 3. Если вы посмотрите внимательно, то вы обнаружите , что таблица 2 представляет собой присоединенную таблицу, которая содержит первичный ключ из обеих таблиц 1 и 2. Как мы сказали, это может быть очень запутанным, чтобы понять объединение трех или более таблиц.

Мы обнаружили, что понимание отношение таблиц в качестве первичного ключа и внешнего ключа помогает облегчить задачу.

SQL Join также является очень популярной темой в SQL и там всегда были некоторые вопросы из соединений, как разница между INNER и OUTER JOIN, например SQL – запрос с JOIN Employee Department и разница между LEFT и RIGHT OUTER JOIN и т.д. Короче говоря это одна из самых важных тем в SQL как из опыта так и из точки зрения цели.

Единственный способ освоить SQL JOIN, это сделать как можно больше упражнений, насколько это возможно. Если бы вы могли решить большинство головоломок SQL из классической книги Джо Селко, SQL Puzzles and Answers, 2nd edition, вы были бы более уверены в работе с SQL JOIN, хоть это быть две, три или четыре таблицы.

Объединение трех таблиц, синтаксис в SQL

Вот общий синтаксис запроса SQL, чтобы присоединить три или более таблиц. Этот SQL-запрос должен работать во всех основных баз данных, например в базе данных MySQL, Oracle, Microsoft SQLServer, Sybase и PostgreSQL:

Мы сначала присоединим таблице 2 к таблице 1, которые создадут временную таблицу с комбинированными данными из table1 и table2, а затем присоединим к Table3. Эта формула может быть распространена на более чем 3 -х таблиц в N таблиц, Вам просто нужно убедиться, что SQL – запрос должен иметь N-1 join, чтобы присоединить N таблиц. Как для объединения двух таблиц мы требуем 1 join а для присоединения 3 таблиц нам нужно 2 join.

Вот хорошая схема, которая хорошо показывает, как применять различные типы присоединений, например как работают в SQL inner, left outer, right outer и cross joins:

SQL запрос по присоединению трех таблиц в MySQL

Для того, чтобы лучше понять присоединение 3 таблицы в SQL запросе, давайте рассмотрим пример. Рассмотрим популярный пример Employee и Department. В нашем случае мы использовали таблицу ссылок под названием Register, который связывает или имеет отношение Employee для Department. Первичный ключ таблицы Employee (emp_id) является внешним ключом в Register и аналогичным образом, первичный ключ таблицы Department (dept_id) является внешним ключом в таблице Register.

Для того , чтобы написать запрос SQL для печати имя сотрудника и название отдела мы должны присоединиться к трем таблицам. Первое присоединение Employee и Register и создают временную таблицу, с колонкой dept_id. Теперь второе присоединение таблицы Department к этой временной таблицы по колонке dept_id, чтобы получить желаемый результат. Вот полный SELECT, пример SQL – запроса, чтобы присоединиться к 3 таблицам, и она может быть расширена, чтобы присоединиться к более чем 3 или N таблицам.

Если вы хотите понять это лучше, попытайтесь объединить таблицы шаг за шагом. Таким образом, вместо того, чтобы присоединиться 3 таблицы за один раз, сначала соединить 2 таблицы и посмотреть, как будет выглядеть таблица результатов. Это все о том, как присоединить три таблицы в одном запросе SQL в реляционной базе данных. Кстати, в этом примере SQL JOIN, мы использовали ANSI SQL, и он будет работать в другой реляционной базы данных, а также, Oracle, SQL Server, Sybase, PostgreSQL и т.д. Дайте нам знать, если вы сталкивались с какой – либо проблемой во время объединения 3 таблицы запросом JOIN в любой другой базе данных.

Если вы нашли ошибку, пожалуйста, выделите фрагмент текста и нажмите Ctrl+Enter.

And what would be for normalized form, if I want to find who is manager over other:

And wants to get this result:

We have 4 tables: name, address, email, phone SELECT A.personID, B.address, C.emailID, D.mobnumber FROM name AS A INNER JOIN address AS B ON A.personID = B.personID INNER JOIN email AS C ON A.personID = C.personID INNER JOIN phone AS D ON A.personID = D.personID This is assuming personID is present in all the tables. This query would display Person ID, Address, Email, Phone number where person ID is same in all the tables since it's an inner join. Hope this helps :)

11 Answers 11

Use ANSI syntax and it will be a lot more clear how you are joining the tables:

@Muhammad: Our answers are the same, they differ only in syntax. If you are not aware of ANSI syntax, it is well worth your time to learn it. It will help you avoid JOIN errors like you have made in the future.

NO, NO, NO, NO, NO! Don't use this legacy, ancient, over 25 year old join syntax any more! Use Explicit joins like in this answer!!

For normalize form

This answer looks very similar to answers already given 5 years earlier. What about your answer do you feel is important, and missing from existing answers?

join query with three tables and we want two values from the same column we set the alias name for every table in the joins. Same table name also declare as a different names.

Don't join like that. It's a really really bad practice. It will slow down the performance in fetching with massive data. For example, if there were 100 rows in each tables, database server have to fetch 100x100x100 = 1000000 times. It had to fetch for 1 million times. To overcome that problem, join the first two table that can fetch result in minimum possible matching(It's up to your database schema). Use that result in Subquery and then join it with the third table and fetch it. For the very first join --> 100x100= 10000 times and suppose we get 5 matching result. And then we join the third table with the result --> 5x100 = 500. Total fetch = 10000+500 = 10500 times only. And thus, the performance went up.

Иногда могут возникать ситуации, когда необходимо получить данные из трех или более таблиц. В этой статье рассматриваются два подхода к его достижению.

Пример:
Создание трех таблиц:

Примечание: нажмите на изображение, если не ясно, чтобы увеличить его.

Таблица 1: студент

Таблица 2: оценки

Таблица 3: детали

Два подхода к объединению трех или более таблиц:
1. Использование соединений в SQL для объединения таблицы:
Применяется та же логика, что и для объединения двух таблиц, т. Е. Минимальное количество операторов объединения для объединения n таблиц равно (n-1) .
Запрос:

Как соединить 3 таблицы в sql

Надо выбрать ВСЕ строки с первой таблицы и по полю TAB выбрать данные DOLJ и OTDEL и добавить данные соответственно.
Во 2-й и 3-й таблицах можно не найти поля TAB с первой таблицы.

select a.tab, a.fam, b.dolj, c.otdel
from a
left join b on a.tab=b.tab
join c on a.tab=c.tab

select a.tab, a.fam, b.dolj, c.otdel
from a
left join b on a.tab=b.tab
left join c on a.tab=c.tab

но это все не то.

Если бы не было нужно выводить ВСЕ строки с первой таблицы, но проблемы бы не было.
А так без LEFT JOIN не включаются записи, инфы по TAB которых нет во 2-й или 3-й таблице, а они нужны, пусть даже с пустыми ячейками.

Как такое реализовать?
Тут были примеры, но все не такие.
Создавать временную таблицу в базе для промежуточного результата(сначала две таблицы соединить во временную, потом так же временную и третью) запрещено.

Добавить в избранное

Объединение трех таблиц, синтаксис в SQL

SQL запрос по присоединению трех таблиц в MySQL

Если вы нашли ошибку, пожалуйста, выделите фрагмент текста и нажмите Ctrl+Enter.

Связи — это довольна важная тема, которую следует понимать при проектировании баз данных. По своему личному опыту скажу, что осознав связи, мне намного легче далось понимание нормализации базы данных.

1.1. Для кого эта статья?

Эта статья будет полезна тем, кто хочет разобраться со связями между таблицами базы данных. В ней я постарался рассказать на понятном языке, что это такое. Для лучшего понимания темы, я чередую теоретический материал с практическими примерами, представленными в виде диаграммы и запроса, создающего нужные нам таблицы. Я использую СУБД Microsoft SQL Server и запросы пишу на T-SQL. Написанный мною код должен работать и на других СУБД, поскольку запросы являются универсальными и не используют специфических конструкций языка T-SQL.

1.2. Как вы можете применить эти знания?

Процесс создания баз данных станет для вас легче и понятнее.
Понимание связей между таблицами поможет вам легче освоить нормализацию, что является очень важным при проектировании базы данных.
Разобраться с чужой базой данных будет значительно проще.
На собеседовании это будет очень хорошим плюсом.

2. Благодарности

Учтены были советы и критика авторов jobgemws, unfilled, firnind, Hamaruba.
Спасибо!

3.1. Как организовываются связи?

Связи создаются с помощью внешних ключей (foreign key).
Внешний ключ — это атрибут или набор атрибутов, которые ссылаются на primary key или unique другой таблицы. Другими словами, это что-то вроде указателя на строку другой таблицы.

3.2. Виды связей

Связи делятся на:

Многие ко многим.
Один ко многим.
- с обязательной связью;
- с необязательной связью;
Один к одному.
- с обязательной связью;
- с необязательной связью;

4. Многие ко многим

Представим, что нам нужно написать БД, которая будет хранить работником IT-компании. При этом существует некий стандартный набор должностей. При этом:

Работник может иметь одну и более должностей. Например, некий работник может быть и админом, и программистом.
Должность может «владеть» одним и более работников. Например, админами является определенный набор работников. Другими словами, к админам относятся некие работники.

4.1. Как построить такие таблицы?

Мы уже имеем две таблицы, описывающие работника и профессию. Теперь нам нужно установить между ними связь многие ко многим. Для реализации такой связи нам нужен некий посредник между таблицами «Employee» и «Position». В нашем случае это будет некая таблица «EmployeesPositions» (работники и должности). Эта таблица-посредник связывает между собой работника и должность следующим образом:

Слева указаны работники (их id), справа — должности (их id). Работники и должности на этой таблице указываются с помощью id’шников.

На эту таблицу можно посмотреть с двух сторон:

Таким образом, мы говорим, что работник с id 1 находится на должность с id 1. При этом обратите внимание на то, что в этой таблице работник с id 1 имеет две должности: 1 и 2. Т.е., каждому работнику слева соответствует некая должность справа.
Мы также можем сказать, что должности с id 3 принадлежат пользователи с id 2 и 3. Т.е., каждой роли справа принадлежит некий работник слева.

4.2. Реализация

С помощью ограничения foreign key мы можем ссылаться на primary key или unique другой таблицы. В этом примере мы

ссылаемся атрибутом PositionId таблицы EmployeesPositions на атрибут PositionId таблицы Position;
атрибутом EmployeeId таблицы EmployeesPositions — на атрибут EmployeeId таблицы Employee;

4.3. Вывод

Для реализации связи многие ко многим нам нужен некий посредник между двумя рассматриваемыми таблицами. Он должен хранить два внешних ключа, первый из которых ссылается на первую таблицу, а второй — на вторую.

5. Один ко многим

Эта самая распространенная связь между базами данных. Мы рассматриваем ее после связи многие ко многим для сравнения.

Предположим, нам нужно реализовать некую БД, которая ведет учет данных о пользователях. У пользователя есть: имя, фамилия, возраст, номера телефонов. При этом у каждого пользователя может быть от одного и больше номеров телефонов (многие номера телефонов).

В этом случае мы наблюдаем следующее: пользователь может иметь многие номера телефонов, но нельзя сказать, что номеру телефона принадлежит определенный пользователь.

Другими словами, телефон принадлежит только одному пользователю. А пользователю могут принадлежать 1 и более телефонов (многие).

Как мы видим, это отношение один ко многим.

5.1. Как построить такие таблицы?

Пользователей будет представлять некая таблица «Person» (id, имя, фамилия, возраст), номера телефонов будет представлять таблица «Phone». Она будет выглядеть так:

PhoneId	PersonId	PhoneNumber
1	5	11 091-10
2	5	19 124-66
3	17	21 972-02

Данная таблица представляет три номера телефона. При этом номера телефона с id 1 и 2 принадлежат пользователю с id 5. А вот номер с id 3 принадлежит пользователю с id 17.
Заметка. Если бы у таблицы «Phones» было бы больше атрибутов, то мы смело бы их добавляли в эту таблицу.

5.2. Почему мы не делаем тут таблицу-посредника?

Таблица-посредник нужна только в том случае, если мы имеем связь многие-ко-многим. По той простой причине, что мы можем рассматривать ее с двух сторон. Как, например, таблицу EmployeesPositions ранее:

Каждому работнику принадлежат несколько должностей (многие).
Каждой должности принадлежит несколько работников (многие).

5.3. Реализация

Наша таблица Phone хранит всего один внешний ключ. Он ссылается на некого пользователя (на строку из таблицы Person). Таким образом, мы как бы говорим: «этот пользователь является владельцем данного телефона». Другими словами, телефон знает id своего владельца.

6. Один к одному

Представим, что на работе вам дали задание написать БД для учета всех работников для HR. Начальник уверял, что компании нужно знать только об имени, возрасте и телефоне работника. Вы разработали такую БД и поместили в нее всю 1000 работников компании. И тут начальник говорит, что им зачем-то нужно знать о том, является ли работник инвалидом или нет. Наиболее простое, что приходит в голову — это добавить новый столбец типа bool в вашу таблицу. Но это слишком долго вписывать 1000 значений и ведь true вы будете вписывать намного реже, чем false (2% будут true, например).

Более простым решением будет создать новую таблицу, назовем ее «DisabledEmployee». Она будет выглядеть так:

Но это еще не связь один к одному. Дело в том, что в такую таблицу работник может быть вписан более одного раза, соответственно, мы получили отношение один ко многим: работник может быть несколько раз инвалидом. Нужно сделать так, чтобы работник мог быть вписан в таблицу только один раз, соответственно, мог быть инвалидом только один раз. Для этого нам нужно указать, что столбец EmployeeId может хранить только уникальные значения. Нам нужно просто наложить на столбец EmloyeeId ограничение unique. Это ограничение сообщает, что атрибут может принимать только уникальные значения.

Выполнив это мы получили связь один к одному.

Заметка. Обратите внимание на то, что мы могли также наложить на атрибут EmloyeeId ограничение primary key. Оно отличается от ограничения unique лишь тем, что не может принимать значения null.

6.1. Вывод

Можно сказать, что отношение один к одному — это разделение одной и той же таблицы на две.

6.2. Реализация

Таблица DisabledEmployee имеет атрибут EmployeeId, что является внешним ключом. Он ссылается на атрибут EmployeeId таблицы Employee. Кроме того, этот атрибут имеет ограничение unique, что говорит о том, что в него могут быть записаны только уникальные значения. Соответственно, работник может быть записан в эту таблицу не более одного раза.

7. Обязательные и необязательные связи

Связи можно поделить на обязательные и необязательные.

7.1. Один ко многим

Один ко многим с обязательной связью:
К одному полку относятся многие бойцы. Один боец относится только к одному полку. Обратите внимание, что любой солдат обязательно принадлежит к одному полку, а полк не может существовать без солдат.
Один ко многим с необязательной связью:
На планете Земля живут все люди. Каждый человек живет только на Земле. При этом планета может существовать и без человечества. Соответственно, нахождение нас на Земле не является обязательным

А) У женщины необязательно есть свои дети. Соответственно, связь необязательна.
Б) У ребенка обязательно есть только одна биологическая мать – в таком случае, связь обязательна.

7.2. Один к одному

Один к одному с обязательной связью:
У одного гражданина определенной страны обязательно есть только один паспорт этой страны. У одного паспорта есть только один владелец.
Один к одному с необязательной связью:
У одной страны может быть только одна конституция. Одна конституция принадлежит только одной стране. Но конституция не является обязательной. У страны она может быть, а может и не быть, как, например, у Израиля и Великобритании.

У одного человека может быть только один загранпаспорт. У одного загранпаспорта есть только один владелец.

А) Наличие загранпаспорта необязательно – его может и не быть у гражданина. Это необязательная связь.
Б) У загранпаспорта обязательно есть только один владелец. В этом случае, это уже обязательная связь.

7.3. Многие ко многим

Человек может инвестировать в акции разных компаний (многих). Инвесторами какой-то компании являются определенные люди (многие).

А) Человек может вообще не инвестировать свои деньги в акции.
Б) Акции компании мог никто не купить.

8. Как читать диаграммы?

Выше я приводил диаграммы созданных нами таблиц. Но для того, чтобы их понимать, нужно знать, как их «читать». Разберемся в этом на примере диаграммы из пункта 5.3.

Мы видим отношение один ко многим. Одной персоне принадлежит много телефонов.

Читайте также: