Схема базы данных, 1 таблица или 2 таблицы

Question

Мое приложение позволит пользователям иметь список контактов. Это моя текущая схема:

CREATE TABLE IF NOT EXISTS `contact` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `user_id` int(11) NOT NULL,
  `person_id` int(11) NOT NULL,
  `create_time` int(11) NOT NULL,
  PRIMARY KEY (`id`),
  UNIQUE KEY `user_id` (`user_id`,`person_id`)
) ENGINE=InnoDB;

CREATE TABLE IF NOT EXISTS `contact_request` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `user_id` int(11) NOT NULL,
  `person_id` int(11) NOT NULL,
  `create_time` int(11) NOT NULL,
  PRIMARY KEY (`id`),
  UNIQUE KEY `user_id` (`user_id`,`person_id`)
) ENGINE=InnoDB;

CREATE TABLE IF NOT EXISTS `user` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `email_address` varchar(50) NOT NULL,
  `username` varchar(32) NOT NULL,
  `password` varchar(32) NOT NULL,
  PRIMARY KEY (`id`),
  UNIQUE KEY `email_address` (`email_address`),
  UNIQUE KEY `username` (`username`)
) ENGINE=InnoDB;

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

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

CREATE TABLE IF NOT EXISTS `contact` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `user_id` int(11) NOT NULL,
  `person_id` int(11) NOT NULL,
  `status` tinyint(1) not null,
  `create_time` int(11) NOT NULL,
  PRIMARY KEY (`id`),
  UNIQUE KEY `user_id` (`user_id`,`person_id`)
) ENGINE=InnoDB;

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

Answer 1

Еще одним преимуществом может быть наличие status (либо INT или CHAR), запросов на запись (Q), принятых контактов (C), отклоненных запросов (J), отклонено и повторно запрошено (R), занесено в черный список (B) и, возможно, другие статусы, чтобы вы могли легче применять более сложные логики, такие как «пользователь не может запросить контакт снова, если он был отклонен дважды» и т. д..

Answer 2

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

Answer 3

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

С другой стороны, единственный плюс, который яМожно видеть, что у вас, хм, на одну таблицу меньше в БД?И очень расплывчатое из-за невозможности случайно иметь контакт существует как в самой таблице контактов, так и в таблице запросов одновременно (ошибка синхронизации или что-то еще).