Система комментариев для двух разных объектов

Question

Я пытаюсь создать систему комментариев.

Конструкция базы данных для вещей, я хотел бы прокомментировать (сообщения и статьи):

TABLE `posts` (
`post_id` int(11) unsigned NOT NULL AUTO_INCREMENT, 
`post_text` text NOT NULL, 
`user_id` int(11) unsigned NOT NULL, 
PRIMARY KEY (`post_id`) 
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci; 

TABLE `articles` (
`article_id` int(11) unsigned NOT NULL AUTO_INCREMENT, 
`article_text` text NOT NULL, 
`user_id` int(11) unsigned NOT NULL, 
PRIMARY KEY (`article_id`) 
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci; 

Проблема
Каждый комментарий должен быть связанных с записью или статьей.

Мои попытки

Вариант № 1
я поставил возможность в article_id, а также post_id в ту же таблицу, и они оба могут быть оставлены пустыми.

TABLE `comments` (
`comment_id` int(11) unsigned NOT NULL AUTO_INCREMENT, 
`comment_text` text NOT NULL, 
`user_id` int(11) unsigned NOT NULL, 
`post_id` int(11) NULL, 
`article_id` int(11) NULL, 
PRIMARY KEY (`article_id`) 
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci; 

Как это там было бы article_id, когда статья комментируется и post_id, если пост комментируется.
Но стоит ли оставлять оба поля NULL, если всегда нужно быть NULL?

Вариант № 2
Создание двух отдельных таблиц. Один для комментариев для комментариев и один для комментариев к статье.

TABLE `article_comments` (
    `comment_id` int(11) unsigned NOT NULL AUTO_INCREMENT, 
    `comment_text` text NOT NULL, 
    `user_id` int(11) unsigned NOT NULL, 
    `article_id` int(11) NOT NULL, 
    PRIMARY KEY (`article_id`) 
    ) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci; 

TABLE `post_comments` (
     `comment_id` int(11) unsigned NOT NULL AUTO_INCREMENT, 
     `comment_text` text NOT NULL, 
     `user_id` int(11) unsigned NOT NULL, 
     `post_id` int(11) NOT NULL, 
     PRIMARY KEY (`article_id`) 
     ) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci; 

Как это никто, кто должен быть NOT NULL является NULL.
Однако я не знаю, может ли это стать проблемой производительности, и я уверен, что это приведет к большому количеству повторений в моем PHP-материале.

Есть ли лучший способ сделать это?

У меня нет опыта в таких вещах и был бы очень благодарен за помощь!

Answer 1

Здесь есть несколько соображений.

Объект против отображений реляционных

PHP предлагает программирование OO-стиль, который позволил бы создать абстрактный класс супер-статьи и поста, к которому комментарии могли бы обобщенно быть связаны между собой. Структуры OO, подобные этому, плохо сопоставляются с реляционными базами данных, но, к сожалению, вам нужно идти на компромиссы.

Прецеденты для доступа к данным

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

Где соблюдение ограничений целостности данных

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

В конечном счете, я не нашел ни одного правильного ответа на эту проблему. Из двух вариантов, которые вы предлагаете выше, Вариант 1 будет моим собственным предпочтением. Однако альтернативой, которую вы должны рассмотреть, является объединение таблиц «Сообщения» и «Статьи» в одну таблицу «Контент» с свойством content_type или аналогичным (что позволяет моделировать их с абстрактным суперклассом и конкретными подклассами в PHP). Тогда ваши таблицы комментариев просто ссылаются на них в целом.