Таблицы ассоциаций «многие ко многим». Обычно ли в эти таблицы добавляются дополнительные столбцы?

Question

Мы столкнулись со следующей ситуацией в нашей базе данных. У нас есть таблица «A» и таблица «B», которые имеют отношение M2M. Таблица ассоциации называется «AB» и содержит столбец FK для таблицы «A» и столбец FK для таблицы «B». Теперь мы определили необходимость хранения дополнительных данных об этой ассоциации. Например, дата, когда произошла связь, кто ее создал и т. Д. Мы решили поместить эти дополнительные столбцы в таблицу ассоциации «AB». Однако, кое-что говорит мне, что это осуждается пуристами базы данных. С другой стороны, нам нет смысла создавать еще одну дополнительную таблицу для хранения этих связанных данных.

Какая распространенная мысль об этом?

Answer 1

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

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

Answer 2

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

Answer 3

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

Answer 4

Если данные на самом деле относятся к связи, а не к одному из отдельных объектов ... тогда да, поместите их в сводную таблицу.

Answer 5

В этом дизайне вы рассматриваете само объединение как сущность. Если этот объект реального мира, отношения между двумя другими объектами, имеет свои собственные атрибуты, то таблица, представляющая это отношение, должна также представлять атрибуты этого отношения.

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

Answer 6

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

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

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

Answer 7

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

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