Лучший способ связать таблицу с 2 разными ключами?

Question

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

Скажем, у меня есть таблица wall_posts. Стены могут принадлежать как событию, так и пользователю. Следовательно, таблица wall_posts должна ссылаться либо на event_id, либо на user_id (ограничение внешнего ключа).

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

Я рассматривал возможность использования 2 таблиц, таких как event_wall_posts и user_wall_posts, чтобы одна получила поле event_id, а другая - user_id, но я считаю, что должно быть что-то намного лучше, чем такая избыточный обходной путь ...

Есть ли способ использовать промежуточную таблицу, чтобы связать wall_posts с event_id или user_id?

Заранее спасибо,

Редактировать: кажется, нет четкого дизайна, чтобы сделать это, и оба подхода кажутся нормальными, так что, какой из них будет самым быстрым, если данных много?

Желательно ли иметь две отдельные таблицы (чтобы запросы могли выполняться быстрее, поскольку в таблицах будет вдвое меньше данных ...), или все же предпочтительнее иметь лучший подход ОО с одной таблицей wall_posts ссылка на настенную таблицу (а затем и на пользователей, и на events will have a unique wall_id`)

Answer 1

Почему это избыточно? Вы не будете писать код дважды для их обработки, вы будете использовать один и тот же код, просто измените имя таблицы в SQL.
Другая причина использования этого подхода заключается в том, что когда-нибудь в будущем вы обнаружите, что вам нужны новые разные поля для каждой сущности.

Answer 2

Выберите самое простое решение: добавьте столбец event_id и user_id в таблицу wall_posts. Используйте ограничения, чтобы одно из них было пустым, а другое - нет.

Что-то более сложное для меня пахнет как сверхнормализация:)

Answer 3

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

Это можно смоделировать несколькими способами:

1. Стол супертипа, скажем, настенный. Две таблицы подтипов (user_wall и event_wall), которые ссылаются на пользователя и событие соответственно как владельца. Таблица wall_posts ссылается на таблицу супертипа; или
2. Помещение обоих типов сущностей в одну таблицу и наличие столбца типа. Таким образом, вы не будете ссылаться на две отдельные таблицы.

Answer 4

Классический подход к этой проблеме:

• Создайте таблицу с именем wall_container и сохраните в ней общие свойства users и events
• Ссылка на users и events на wall_container
• Ссылка wall_posts на wall_container

Однако это не очень эффективно, и не гарантируется, что этот wall_container не содержит записей, которые не являются user или event.

SQL не особенно хорош в обработке множественного наследования.

Answer 5

У вашей стены и мероприятия есть свои уникальные идентификаторы .. правильно ?? тогда им не нужен другой стол. пусть таблица wall_post имеет атрибут источника, который будет указывать на запись того, кем является запись события или пользователя. «

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