Enum vs Справочная таблица vs Класс поиска

Question

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

После прочтения нескольких мнений я почти отказался от использования enum , например:

CREATE TABLE profile (
  'user_id' INT NOT NULL,
 ...
  'relationship_status' ENUM('Single','Married') NOT NULL,
 ... 
);

И обычно я использую справочную таблицу , например:

CREATE TABLE profile (
  'user_id' INT NOT NULL,
 ...
  'relationship_status_id' INT NOT NULL, 
 ... 
);

CREATE TABLE relationship_status (
  'id' INT NOT NULL,
  'name' VARCHAR(45) NOT NULL,
  PRIMARY KEY ('id') 
);

Но создание 32 таблиц может оказаться слишком сложным, поэтому я рассматриваю кодирование в PHP вот так:

class RelationshipStatusLookUp{
  const SINGLE = 1;
  const MARRIED = 2;

  public static function getLabel($status){
      if($status == self::SINGLE)
         return 'Single';
      if($status == self::MARRIED)
         return 'Married';
      return false;
  }
}

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

Спасибо.

Answer 1

Определенно хорошая идея держаться подальше от ENUM ИМХО: почему ENUM - зло . Технически предпочтительной является таблица поиска, хотя для простых значений будет работать класс PHP. Вы должны быть осторожны с этим по тем же причинам, что и ENUM; если значения в вашем наборе растут, поддерживать их может быть сложно. (А как насчет "совместного проживания", "разведенных", "гражданского партнерства", "овдовевших" и т. Д.). Также нетривиально запрашивать списки значений с использованием классов PHP; это возможно, используя отражение, но не так просто, как простой SELECT MySQL. Вероятно, это один из тех случаев, когда я не стал бы беспокоиться о производительности, пока она не станет проблемой. Сначала используйте лучшее решение для своего кода / приложения, а затем оптимизируйте, если вам нужно.

Answer 2

перечисление полей представляют некоторые проблемы:

• После того, как они установлены, они не могут быть легко изменены

  'relationship_status' ENUM('Single','Married') NOT NULL,
  

  потребуется добавить «Гражданское партнерство»в этой стране в настоящее время

• Вы не можете легко создать выпадающий список опций из списков перечисления

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

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

Лично я бы пошел за справочной таблицей

Answer 3

Во-первых, вам не понадобятся id и relationship_status_id в таблице Relationship_status.

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

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