"Внешние ключи" одной таблицы к двум другим в MySQL. Можно и как?

Question

[Дмитрий Ким]

Есть таблица комментариев. Также есть таблицы новостей, объявлений и компаний.
В комментариях записи хранятся с дополнительным полем принадлежности (вроде content_type = news | catalog | market).
Тем самым у каждой сущности из последних трех может быть много связей с первой таблицей.
Можно ли как-то организовать внешние ключи comments <=> news + comments <=> market + comments <=> catalog как-то используя это поле? Или единственный выход - создание промежуточной таблицы со связями, а уже там создавать связь с таблицей комментариев? Но тогда ведь теряется связь между тремя таблицами сущностей и таблицей с их связями?

Answer 1

[Алексей]

Тоесть вы по логике разбили разделы, но не разбили комментарии к ним ?
Я бы предложил не делать промежуточные, а присоединить каждый к каждому.
news <=> news_comments, market <=> market_comments, catalog <=> catalog_comments
Это будет намного проще и эффективней.
Второй вариант сделать content_type = news | catalog | market не для комментариев, а для контента, т.е. таблица content с enum полем принадлежности news | catalog | market и таблица коментов с внешним ключем на поле content_id.

Comments

[Дмитрий Ким]

Создавать 3 идентичные таблицы комментариев - как-то не кошерно. А общая таблица для 3 разных сущностей с совершенно разными полями - тоже не вариант. Допускаю использование второго варианта, но с вынесением всех отличающихся полей в отдельные таблицы. Хотя тоже не полноценное решение, т.к. нет возможности опять же повесить внешние ключи.

[Алексей]

Дмитрий Ким: вы точно правильно понимаете что есть сущности ? Хотелось бы знать чем радикальным у вас отличаются таблицы news catalog и market между собой, кроме значений поля id. Если это точно такойже дескрипшен, текст и заголовок у всех 3х, то это в любом случае одна сущность и бессмысленно было их делить на 3, но если уж сделали, то и комментарии к ним должны идти отдельными сущностями. Если проект работает еще не в полную силу, советую полностью пересмотреть архитектуру базы и прочитать статьи про реляционные модели. Если проект раскочегарен, делайте промежуточную таблицу, но это уже будет выглядеть не как спланированная база, а как заплатка или костыль.