В чем необходимость соединительных таблиц?

Как я это вижу, у вас есть несколько сущностей

CREATE TABLE StudentType
(
    Id Int PRIMARY KEY,
    Name NVarChar(50) 
);

INSERT StudentType VALUES
(
    (1, 'Basic'),
    (2, 'Advanced'),
    (3, 'SomeOtherCategory')
);

CREATE TABLE Student
(
    Id Int PRIMARY KEY,
    Name NVarChar(200),
    OtherAttributeCommonToAllStudents Int,
    Type Int,
    CONSTRAINT FK_Student_StudentType
        FOREIGN KEY (Type) REFERENCES StudentType(Id)
)

CREATE TABLE StudentAdvanced
(
    Id Int PRIMARY KEY,
    AdvancedOnlyAttribute Int,
    CONSTRIANT FK_StudentAdvanced_Student
        FOREIGN KEY (Id) REFERENCES Student(Id)
)

CREATE TABLE StudentSomeOtherCategory
(
    Id Int PRIMARY KEY,
    SomeOtherCategoryOnlyAttribute Int,
    CONSTRIANT FK_StudentSomeOtherCategory_Student
        FOREIGN KEY (Id) REFERENCES Student(Id)
)

1. Все атрибуты, общие для всех учащихся, имеют столбцы в таблице Student.
2. Типы учеников, которые имеют дополнительные атрибуты, добавляются в таблицу StudentType.
3. Каждый дополнительный тип учащегося получает таблицу Student<TypeName> для хранения своих конкретных атрибутов. Эти таблицы имеют необязательное взаимно-однозначное отношение с Student.

Я думаю, что ваша соединительная таблица «соломенный человек» является частичной реализацией анти-шаблона EAV, единственный раз, когда это разумно, - это когда вы не можете знать, какие атрибуты вам нужно моделировать, т. е. ваши данные будут полностью неструктурированы . Когда это действительно необходимо, реляционные базы данных становятся менее желательными. В таких случаях рассмотрите альтернативу базе данных NOSQL/Document.

Таблица соединений будет полезна в следующем сценарии.

Скажем, мы добавляем в модель объект класса.

CREATE TABLE Class
(
    Id Int PRIMARY KEY,
    ...
)

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

CREATE TABLE Registration
(
    Id Int PRIMARY KEY,
    StudentId Int,
    ClassId Int,
    CONSTRAINT FK_Registration_Student
        FOREIGN KEY (StudentId) REFERENCES Student(Id),
    CONSTRAINT FK_Registration_Class
        FOREIGN KEY (ClassId) REFERENCES Class(Id)
)

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

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

Когда существует отношение «многие ко многим» без каких-либо атрибутов, я согласен с тем, что логически соединительная таблица не должна существовать. Однако в реляционной базе данных соединительные таблицы по-прежнему являются полезной физической реализацией, например, такой:

CREATE TABLE StudentClass
(
    StudentId Int,
    ClassId Int,
    CONSTRAINT PK_StudentClass PRIMARY KEY (ClassId, StudentId),
    CONSTRAINT FK_Registration_Student
        FOREIGN KEY (StudentId) REFERENCES Student(Id),
    CONSTRAINT FK_Registration_Class
        FOREIGN KEY (ClassId) REFERENCES Class(Id)
)

это позволяет выполнять простые запросы, например

// students in a class?
SELECT StudentId
FROM StudentClass
WHERE ClassId = @classId

// classes read by a student?
SELECT ClassId
FROM StudentClass
WHERE StudentId = @studentId

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