MYSQL объединяет таблицы на основе данных столбца и имени таблицы - PullRequest
Новая
       24

MYSQL объединяет таблицы на основе данных столбца и имени таблицы

10 голосов
/ 17 ноября 2011

Интересно, возможно ли это?

Я хочу объединить 2 таблицы на основе данных таблицы 1. Пример таблицы 1 содержит столбец food с данными "hotdog".

И у меня есть стол под названием хот-дог.

МОЖНО ЛИ СОГЛАСОВАТЬ. 

SELECT * FROM table1 t join t.food on id = foodid

Я знаю, что это не работает, но, даже возможно, есть ли работа вокруг?.

Заранее спасибо.

Ответы [ 2 ]

11 голосов
/ 17 ноября 2011

Нет, вы не можете присоединиться к другой таблице на строку в table1, даже с динамическим SQL, как рекомендует @Cade Roux.

Вы можете присоединиться к таблице hotdog для строк, где еда - «хот-дог», и присоединиться к другим таблицам для других конкретных значений еды. 

SELECT * FROM table1 JOIN hotdog ON id = foodid WHERE food = 'hotdog'
UNION
SELECT * FROM table1 JOIN apples ON id = foodid WHERE food = 'apples'
UNION
SELECT * FROM table1 JOIN soups  ON id = foodid WHERE food = 'soup'
UNION 
...

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

То, что вы делаете, называется полиморфными ассоциациями .То есть внешний ключ в table1 ссылается на строки в нескольких «родительских» таблицах, в зависимости от значения в другом столбце table1.Это распространенная ошибка проектирования программистов реляционных баз данных.

Альтернативные решения см. В моих ответах на:

Я также рассматриваю решения для полиморфных ассоциаций в своей презентации Практические объектно-ориентированные модели в SQL и в моей книге Антипаттерны SQL: предотвращение ловушек при программировании баз данных .

0 голосов
/ 17 ноября 2011

Только с динамическим SQL.Можно также объединить множество различных таблиц и использовать CASE на основе типа, но все таблицы должны быть известны заранее.

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

Say you have a table of foods:

id INT
foodtype VARCHAR(50) (right now it just contains 'hotdog' or 'hamburger')
name VARCHAR(50)

Then hotdogs:

id INT
length INT
width INT

Then hamburgers:

id INT
radius INT
thickness INT

Обычно я бы рекомендовал какую-то систему для ограничения только одной вспомогательной таблицысуществует, но для простоты я опускаю это. 

SELECT f.*, hd.length, hd.width, hb.radius, hb.thickness
FROM foods f
LEFT JOIN hotdogs hd
    ON hd.id = f.id
    AND f.foodtype = 'hotdog'
LEFT JOIN hamburgers hb
    ON hb.id = f.id
    AND f.foodtype = 'hamburger'

Теперь вы увидите, что такая вещь может быть сгенерирована кодом (или даже для очень медленного прототипа динамического SQL на лету) из SELECT DISTINCT foodtype FROM foods учитывая определенные предположения об именах таблиц и доступе к метаданным таблиц.

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

Таким образом, вопрос возвращается к вашему клиенту / потребителю данных - как это происходит?нг обрабатывать разные типы?И что значит для разных типов быть в одном наборе?И если ему необходимо знать о различных типах, в чем заключается недостаток простого написания разных запросов для каждого типа или изменения запроса вручную при добавлении новых типов, учитывая относительное влияние такого изменения в любом случае?

...