Łączenie tabel MYSQL na podstawie danych kolumny i nazwy tabeli

Question

Zastanawiam się, czy jest to nawet możliwe.

Chcę dołączyć 2 tabele w oparciu o dane z tabeli 1. Przykładowa tabela 1 zawiera jedzenie kolumnowe z danymi "hotdog".

Mam też stół o nazwie Hotdog.

JEST możliwe, aby wykonać DOŁĄCZ jak.

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

Wiem, że to nie działa, ale, nawet jeśli jest to możliwe, czy istnieje jakieś dzieło sztuki ?.

Z góry dziękuję.

Answer 1

Nie, nie można dołączyć do innej tabeli w wierszu w table1, nawet z dynamicznym SQL, jak sugeruje @Cade Roux.

Możesz dołączyć do tabeli hotdog dla wierszy, w których żywność jest "hotdogiem" i dołączyć do innych tabel dla innych określonych wartości żywności.

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 
... 

Wymaga to, że znasz wszystkie odrębne wartości żywności i że wszystkie odpowiednie tabele żywnościowe mają kompatybilne kolumny, dzięki czemu można UNION nich razem.

Co robisz nazywa się stowarzyszeń polimorficznych. Oznacza to, że klucz obcy w table1 odwołuje się do wierszy w wielu tabelach "nadrzędnych", w zależności od wartości w innej kolumnie table1. Jest to powszechny błąd projektowy relacyjnych programistów baz danych.

alternatywnych rozwiązań, aby zobaczyć moje odpowiedzi:

• Possible to do a MySQL foreign key to one of two possible tables?
• Why can you not have a foreign key in a polymorphic association?

ja również obejmować rozwiązania dla polimorficznych stowarzyszeń w mojej prezentacji Practical Object Oriented Models In SQL iw mojej książce SQL Antipatterns: Avoiding the Pitfalls of Database Programming.

Answer 2

Tylko z dynamicznym SQL. Możliwe jest również pozostawienie łączenia wielu różnych tabel i użycie CASE na podstawie typu, ale wszystkie tabele muszą być znane z góry.

Łatwiej byłoby polecić odpowiedni projekt, gdybyśmy wiedzieli więcej o tym, co próbujesz osiągnąć, jak wygląda twój projekt i dlaczego wybrałeś właśnie ten konkretny projekt stołu.

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 

Normalnie bym polecić jakiś system ograniczający tylko jeden stół pomocniczy istnieć, ale dla uproszczenia, że ​​wyjeżdżam na zewnątrz.

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' 

Teraz widać, że coś takiego może być wygenerowany kod (lub nawet na bardzo powolnym prototypu dynamicznego SQL w locie) od SELECT DISTINCT foodtype FROM foods podanych pewnych założeń dotyczących nazw tabel oraz dostęp do metadanych tabeli.

Problem polega na tym, że ostatecznie każdy, kto zużyje wynik tego zapytania, będzie musiał pamiętać o nowych kolumnach pojawiających się po dodaniu nowej tabeli.

W związku z tym pytanie wraca do klienta/konsumenta danych - w jaki sposób poradzi sobie z różnymi typami? A co to znaczy, że różne typy znajdują się w tym samym zestawie? A jeśli trzeba wiedzieć o różnych typach, jaka jest wada pisania różnych zapytań dla każdego typu lub zmieniania ręcznego zapytania, gdy nowe typy są dodawane ze względu na względny wpływ takiej zmiany?