У меня есть быстрый вопрос по отношению ко многим отношениям в sql. Итак, теоретически я понимаю, что если 2 объекта в модели ER имеют отношение M: N между ними, мы должны разбить это на 2 отношения 1: N с включением таблицы пересечения/поиска, которая имеет составной первичный ключ от обоих родительские таблицы. Но, мой вопрос здесь, в дополнение к составному первичному ключу, может ли быть какой-либо дополнительный дополнительный столбец, добавленный в составную таблицу, которые не входят ни в одну из двух родительских таблиц? (кроме intersectionTableId, table1ID, table2ID) 4-й столбец, который является совершенно новым, а не ни в одной из двух родительских таблиц? Пожалуйста, дайте мне знать.запрос с SQL m: n отношения
ответ
Да, вы можете сделать это, самостоятельно моделируя таблицу отношений (так же, как и ваши другие сущности).
Вот несколько сообщений о том, что именно этот вопрос.
Create code first, many to many, with additional fields in association table
Entity Framework CodeFirst many to many relationship with additional information
Спасибо всем :) очень благодарен. – Vish
Одним словом - да. Общепринятой практикой является определение свойств взаимосвязи между двумя объектами.
Е.Г., считают вас есть база данных, хранящую сведения людей и спортивных команд, им нравится:
CREATE TABLE person (
id INT PRIMARY KEY,
first_name VARCHAR(10),
last_name VARCHAR(10)
);
CREATE TABLE team (
id INT PRIMARY KEY,
name VARCHAR(10)
);
Человек может нравится больше, чем одна команда, которая является ваш классический M: N таблица отношений. Но вы могли бы также добавить некоторые сведения к этому объекту, например, когда пользователь начал симпатизировать команде:
CREATE TABLE fandom (
person_id INT NOT NULL REFERENCES person(id),
team_id INT NOT NULL REFERENCES team(id),
fandom_started DATE,
PRIMARY KEY (person_id, team_id)
);
Какая СУБД это и как создается таблица пересечений? –
Абсолютно! Данные об ассоциации BELONGS на такой таблице. Подумайте о базе данных клиентов/фильмов. Я хочу знать, что клиент проверил, какой фильм у клиента может иметь много фильмов, и фильм может быть проверен только одним клиентом за раз; но я хочу, чтобы история фильмов была проверена и узнала, когда она была возвращена. В ассоциативной таблице может быть Checkout и CheckIn; это скажет мне историю и продолжительность проверок для клиента и, возможно, основанные на ролях фильмов и клиенте, снятых напрокат фильмах, может быть создан список предложений ... – xQbert