Обработка стратегии первичного ключа Heroku/ClearDB с автоматическим приращением
С 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
}
Очевидно, что это сломается из-за способ увеличения числа ПК. Какова наилучшая практика для решения подобных ситуаций? Я не могу, например, проверить наличие 14, так как нечего сказать, что стратегия нумерации не изменится на 12, 22, 32 и т.д.
Должен ли я проверять по имени, например, if($status['name'] == 'Active'), или я должен добавить новый столбец в таблицу с int, которые мне требуются? Я знаю, что запрос с помощью int в SQL намного быстрее, чем с помощью string.
Итак, каков нормальный способ справиться с этим?
1 answers
В основном существуют две стратегии для решения этой проблемы
Нет автоматического увеличения
Не используйте автоматическое увеличение. Просто добавьте значения идентификаторов самостоятельно при вставке данных. Для такой таблицы, как "статус", которая, вероятно, содержит только статические данные, вы не изменяете динамически, это может быть хорошим вариантом.
Строковые константы
Проверьте строковые значения. И определите эти строки как константы класса.
class YourClass {
const ACTIVE = 'Active';
const RETIRED = 'Retired';
...
}
А затем запишите свои чеки как
if($status['name'] == self::ACTIVE){
//do something
}
Я бы рекомендую использовать второй подход, в основном потому, что он делает ваш код более семантическим. Гораздо проще понять, что означает $status['name'] == self::RETIRED, чем $status['id'] == 2
И если вы добавите индекс в столбец name в этой таблице, не будет (почти) никакой разницы в производительности при запросе по имени, а не по первичному ключу.