Relacja wiele do wielu - kraje oraz kontynenty w wielu językach

0

Zaprojektowałem dwie tabele - kraje oraz kontynenty
Każdy kraj może być w wielu językach oraz każdy kontynent może być w wielu językach, jednak umieszczone jest tłumaczenie się pojawiła się dodatkowa kolumna jako numer kraju oraz numer kontynentu

Czy jest to zrobione poprawnie?

CREATE TABLE `continents` (
    `id` int(11) NOT NULL,
    `language` int(11) NOT NULL,
    `continent` varchar(255) COLLATE utf8mb4_unicode_ci NOT NULL,
    `continent_number` int(11) NOT NULL,
    PRIMARY KEY (`id`),
    FOREIGN KEY (`language`) REFERENCES `languages`(`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci;

INSERT INTO `continents` (`id`, `language`,`continent_number`, `continent` ) VALUES
(1, 1, 1,'Europa'),
(2, 1, 2,'Azja'),
(3, 1, 3,'Ameryka Północna'),
(4, 1, 4,'Ameryka Południowa'),
(5, 1, 5,'Afryka'),
(6, 1, 6,'Australia'),
(7, 1, 7,'Antarktyda'),
(8, 2, 1,'Europe'),
(9, 2, 2,'Asia'),
(10, 2, 3,'North America'),
(11, 2, 4,'Sounth America'),
(12, 2, 5,'Africa'),
(13, 2, 6,'Australia');

CREATE TABLE `countries`
(
    `id` int(11) NOT NULL,
    `language` int(11) NOT NULL,
    `country` varchar(255) COLLATE utf8mb4_unicode_ci NOT NULL,
    `country_number` int(11) NOT NULL,
    `continent` int(11) NOT NULL,
    PRIMARY KEY (`id`),
    FOREIGN KEY (`language`) REFERENCES `languages`(`id`)
    #FOREIGN KEY (`continent`) REFERENCES `continents`(`continent_number`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci;

INSERT INTO `countries` (`id`, `language`,`country_number`,`continent`, `country` ) VALUES
(1, 1, 1, 1, 'Polska'),
(2, 2, 1, 1, 'Polish'),
(3, 1, 2, 1, 'Wielka Brytania'),
(4, 1, 3, 1, 'Stany Zjednoczone'),
(5, 1, 4, 1, 'Niemcy'),
(6, 1, 5, 1, 'Francja'),
(7, 1, 6, 1, 'Włochy'),
(8, 1, 7, 1, 'Hiszpania');
0

Dobra już doczytałem, to normalne, zrobiła się tabela pośrednia w stylu tabela1 relacja jeden do wielu tabela_posrednia relacja wiele do jednego tabela2

A próbując zilustrować

tabela1 ---< tabela_posrednia >-- tabela2

0

Czy mogę dodać relację wiele do wielu pomiędzy continent z tabelu countries a continent_number z tabeli continents?
Zależy mi aby nie tworzyć wielu tabel

0

Niespecjalnie podoba mi się taka konstrukcja. Encje jak sam napisałeś, to kraj i kontynent. A nie kraj_w_jakimś_języku i kontynent_w_jakimś_języku.
Taka struktura jaką zaprojektowałeś wymaga wpisywania za każdym razem kraju czy kontynentu, gdy potrzebujesz obsłużyć nowy język. W krajach to się w ogóle bałagan zrobi, bo każdą wersję językową kraju musisz przypisać do każdej wersji językowej kontynentu.

Czemu nie zrobisz: continents, continents_lang, countries, countries_lang? Każdy kontynent i kraj ma powiązanie z odpowiednią wersją językową. Możesz też w kontynentach i krajach podać nazwę w języku domyślnym, a pozostałe (ale domyślny też) trzymać w pomocniczych tabelach. A klucz do "languages" to wtedy będzie w continents_lang i countries_lang.
Kraj jest tylko raz powiązany z kontynentem (hmm, jest jakiś który leży w więcej niż jednym na raz?).

Jeśli operujesz na krajach to warto podać kod kraju, np. wg standardu ISO 3166-1. Ale tu znów uwaga - kody te występują w różnych wersjach: 2 lub 3 znakowe albo liczbowe.
Tu się sytuacja komplikuje, gdy chcesz przechowywać kody związane np. z tablicami rejestracyjnymi samochodów albo nazwami domen. Wtedy kraj powinien posiadać możliwość powiązania z kodami z różnych dziedzin. I kolejna niespodzianka - są twory, które nie są oficjalnie krajami, ale swoje domeny (czy inne rodzaje kodów) posiadają, np. Palestyna. Surprise! :)

P.S.
Nazwy tabel i kolumn podajesz w apostrofach (a właściwie w akcentach) - po co? Wydaje mi się, że potem będziesz musiał używać tylko małych liter przy tworzeniu zapytań odwołujących się do tych tabel. Dobra zasada w SQL - nie wymuszaj wielkości liter w nazwach.

No i Polska to Poland, a nie Polish.

P.P.S.
Tworzy się czasem takie konstrukcje jak podałeś, ale to wynika z optymalizacji jakiegoś systemu i np. wymaga partycjonowania danych wg kodu języka czy kraju, żeby przyspieszyć pobieranie danych.

1 użytkowników online, w tym zalogowanych: 0, gości: 1, botów: 0