Много ко многим - соединительный стол

Question

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

user 1 speak 3 languages

    user_id|first language|secondlanguage|thirdlanguage|fourthlanguage| fifthlanguage 
    1        english (1)     franch(2)    portuguese (3)      null           null 

Что вы думаете об этой схеме?Звучит немного странно, или это правильный способ сделать это?

Answer 1

Ответ на этот вопрос в том, что это действительно зависит.Реляционные пуристы скажут, что это повторяющаяся группа, и это ужасный замысел, в то время как толпа быстрого и грязного толка скажет: «Если вы когда-нибудь будете поддерживать только 5 языков, то сделайте это».Но на самом деле - как вы можете быть уверены, что всегда будете поддерживать только 5 языков?И какие виды запросов вы будете делать?Представьте, что вы хотите найти всех людей, говорящих по-английски - ваш запрос будет:

select * from single_user_has_spoken_languages where lang1 = @englishID or lang2 = @englishID or... etc

Если вы хотите найти людей, говорящих по-английски и по-французски, то ваш пункт where снова возрастет.И каждый отдельный запрос должен будет измениться, если вы добавите шестой язык.

Рассмотрите альтернативный вариант:

select distinct UserID from single_user_has_spoken_languages where langID = @englishID

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

Answer 2

Я бы нормализовал языки.

Так, например (не ключевые столбцы опущены для краткости):

Language Table
id:  INT

Single_User Table
id:  INT

User_Language Table
user_id: INT
language_id: INT
language_num:  SMALLINT

Вы можете наложить уникальные ограничения на user_id, language_id кака также user_id, language_num для обеспечения отсутствия дубликатов.Вы также можете установить контрольное ограничение для language_num, которое будет между 1 и 5, чтобы гарантировать, что выбраны только 5 языков.

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

Answer 3

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

Table User: User_ud, name, etc
Table Language: user_id, fluency, name

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

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