2013-10-11 2 views
2

У меня есть таблица причин запрета:Избегайте жесткого кодирования в MySQL Query

id | short_name | description 
1  virus  Virus detected in file 
2  spam  Spammy file 
3  illegal Illegal content 

Когда я запретить файл за то, что вирус, в моем коде я это делаю:

$file -> banVirus(); 

Какие вкладыши идентификатор файла и запрет в таблицу:

"INSERT INTO 'banned_files' VALUES (61234, 1)" 

Мой вопрос: Проблема в том, что я жестко закодировал значение 1?, чтобы указать спам-файл.

Должен ли я использовать определения в моей конфигурации, такие как define ('SPAM', 1), поэтому я могу заменить 1 на определение? Или это вообще не имеет значения?

+0

Почему бы вам просто не сделать это необязательным параметром? –

+0

Если вы сохранили код, что бы вы хотели видеть в источнике, 'SPAM' или' 1'? –

+0

Выглядит хорошо, поскольку у вас есть только 3 типа запрета, их очень легко запомнить. Если бы у вас было более 50 из них, я бы подумал иначе. – H2ONOCK

ответ

2

Если id - это автоинкрементное поле, то это очень большая проблема! Поскольку идентификаторы автоматически генерируются, трудно гарантировать их стабильность; то есть они могут измениться.

Если id - это то, что вы назначили вручную, это не такая уж большая проблема, но это плохая практика. Потому что магические числа легко приводят к путанице и ошибкам. Кто знает, что означает «1» при чтении кода?

Итак, в любом случае вам будет лучше назначить стабильный, читаемый идентификатор для каждого случая .

Я согласен с @Tenner, что также вряд ли имеет смысл иметь таблицу для этих статических, неизменных данных для начала. Ваша banned_files таблица должна иметь столбец так:

reason ENUM('virus', 'spam', 'illegal') NOT NULL 

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

+0

Я не согласен с вашим первым заявлением. Хотя это может быть поле автоинкремента, оно находится в таблице «поиска». Существует другая таблица, banned_files, которая имеет внешний ключ к файлам запрещенных причин. – AgRizzo

+2

Итак? Но «1» жестко закодирован в PHP, а идентификатор может измениться в базе данных. Это неустойчивые отношения, поэтому проблема. – deceze

+0

Это кажется лучшим решением для вставки. Если возможно, можете ли вы представить простой пример того, как добавить читаемую причину с помощью массива? – paul

1

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

Подумайте о чем-то вроде пола - у которого есть два (или более) варианта, оба фиксированные. (Мы не будем добавлять несколько новых родов в ближайшее время.) Я гарантирую, что большинство систем регистрации «не имеют таблицы GENDER с двумя записями в ней».

Таким образом, таблица banned_files будет что-то вроде этого:

id  | reason 
--------+------------ 
12345 | 1 
67890 | 2 

и ваш код будет содержать перечислений по мере необходимости:

enum BanReason { 
    Virus = 1, 
    Spam = 2, 
    Illegal = 3 
} 

(пожалуйста преобразовать в PHP, я разработчик C#!)

В PHP:

$aBanReason = array(
    'Virus' => 1, 
    'Spam' => 2, 
    'Illegal' => 3 
); 
+2

Поскольку идентификатор используется на уровне базы данных как значение столбца, это не очень хорошая практика, чтобы описать его в некоторый случайный код с перечислениями. Он соединяет два, это, конечно, не ясно, если потребуется, чтобы посмотреть его в будущем. Наличие таблицы словарей является обычной практикой, если значение не является двоичным, как GENDER, как вы упомянули, где будет достаточно TINYINT в MySQL, и имя столбца описывает себя. – melc

+0

+1, я не согласен. – Tenner

+0

Спасибо за помощь PHP, @ CD001! – Tenner

Смежные вопросы