Enum vs Reference table vs Lookup class

Пока я создаю базу данных 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;
  }
}

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

Спасибо.

Ответ 1

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

Ответ 2

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

Как только они установлены, их нельзя легко изменить
```
'relationship_status' ENUM('Single','Married') NOT NULL,
```
в настоящее время необходимо добавить "Гражданское партнерство" в этой стране
Вы не можете легко создать раскрывающийся список опций из списков перечисления

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

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

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

Ответ 3

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

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

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