Оптимизация отношений многие ко многим

Я работаю над системой, в которой у меня есть таблица для хранения языковых компетенций студентов, чтобы управлять этим, мы создали следующую архитектуру:

таблица STD_LANGUAGE_COMPETENCIES представляет ассоциативный объект. отношения «многие ко многим» между таблицей STD_LANGUAGE (французский, английский, арабский...) и STD_LANGUAGE_SKILL (чтение, разговорная речь, письмо, обучение) проблема заключается в том, что STD_LANGUAGE и STD_LANGUAGE_SKILL не обновляются обычным пользователем системы (учащийся ) они добавляются системным администратором , и когда я пытаюсь получить языковые компетенции для студента , архитектура обязывает меня выполнить объединение двух таблиц , чтобы получить название языка и название навыка . есть ли способ оптимизировать эту схему.


person aouakki    schedule 04.08.2016    source источник
comment
вы рассматривали возможность создания представления?   -  person Ian Kenney    schedule 04.08.2016
comment
Я создаю API   -  person aouakki    schedule 04.08.2016


Ответы (2)


Если языковые навыки, например: "чтение", "письмо", "разговор" и т. д., без перестановки имен, без ограничения времени на навыки и управление клиентскими модулями, вы можете поместить описание прямо в таблицу STD_LANGUAGE_COMPETENCE, и удалите ограничения внешнего ключа, в то время как вы сохраните таблицу навыков для комбо-элементов для назначения или поиска (по тексту).

Таким образом, вы можете избежать соединения.

person Ciro Corvino    schedule 04.08.2016

Если у вас есть отношения «один ко многим» или «многие ко многим». Вы не можете избежать соединения, чтобы следовать структуре нормализации в SQL.

person Ambika    schedule 04.08.2016