Обработка Heroku/ClearDB auto Приращение стратегии первичного ключа

Когда Heroku запускает ClearDB в качестве уровня MySQL, первичные ключи автоматически увеличиваются в 10 раз. Так, например, первая вставка может быть 4, затем 14, 24, 34 и т.д. Я полностью согласен с их аргументацией в этом вопросе, так что не проблема.

Мой вопрос: как вы справляетесь с этим в своем коде. Например, допустим, что у меня есть таблица status, состоящая из 4 строк,

     id | name
     1  | Active
     2  | Retired
     3  | Banned
     4  | Awaiting Mod

И затем в моем приложении я использую:

   if($status['id'] == 1){
     //do something
   }else{
     // do something else
   }

Ясно, что это сломается из-за того, как увеличивается PK. Какова наилучшая практика для таких ситуаций? Я не могу, например, проверить 14, так как нечего сказать, что стратегия нумерации не изменится на 12, 22, 32 и т.д.

Нужно ли проверять по имени, например, if($status['name'] == 'Active'), или добавить новый столбец в таблицу с помощью int, который мне нужен? Я знаю, что запрос int в SQL намного быстрее, чем string.

Итак, каков нормальный способ справиться с этим?

ОТВЕТЫ

Ответ 1

В основном есть две стратегии для обработки этого

Нет автоматического приращения

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

Строковые константы

Проверьте строковые значения. И определите эти строки как константы классов.

class YourClass {
  const ACTIVE = 'Active';
  const RETIRED = 'Retired';
  ...
}

И затем напишите свои чеки как

if($status['name'] == self::ACTIVE){
  //do something
}

Я бы рекомендовал использовать второй подход, главным образом потому, что он делает ваш код более семантическим. Его гораздо легче понять, что означает $status['name'] == self::RETIRED, чем $status['id'] == 2

И если вы добавите индекс в столбец name в этой таблице, то не будет (почти) какой-либо разницы в производительности при запросе по имени вместо первичного ключа.