Лучшие практики для обновления с MySQL на PDO

Question

Я обновляю кодовую базу с mysql до pdo, и я впервые делаю такой проект, поэтому я изучаю лучшие практики и хотел бы получить какой-то вклад. Вот старый код:

$link = @mysql_connect('localhost', "xxx", "xxx")

 or die('Could not connect: ' . mysql_error());

mysql_select_db("xxx") or die('Could not select database');

В своем коде я помещаю все учетные данные для входа в отдельный файл и использую IP-адрес, имя пользователя и пароль для подключения, а не localhost.

try {
    $pdo = new PDO($dsn, $user, $password);
    $pdo->setAttribute(PDO::ATTR_DEFAULT_FETCH_MODE, PDO::FETCH_ASSOC);
    $pdo->setAttribute(PDO::ATTR_EMULATE_PREPARES, false);
    $dbh->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);
} catch (PDOException $e){
    log_error("Failed to run query", $e->getMessage(), $e->getCode(), array('exception' => $e));
    die('Could not connect!');

Два вопроса. Является ли это хорошей альтернативой использованию метода die, работающего с ошибками и ведением журнала клиенту, а также это правильный способ подключения? Есть ли преимущество подключения с использованием localhost по сравнению с IP-адресом сервера? Спасибо за помощь!

Answer 1

Является ли это хорошей альтернативой использованию метода die?

То, что вы делаете, является разумным с точки зрения миграции - оно должно вести себя так же, как и раньше. Однако вы можете подумать, что не может перехватить это PDOException и разрешить его выдачу вплоть до вашего глобального обработчика ошибок. Это лучше, потому что меньше кода, и вы не поймаете исключение только на die. Но прежде чем внести это изменение, вы должны иметь представление о том, как оно будет вести себя в ваших производственных системах (вы увидите ошибку в своих журналах)?

Это правильный способ подключения?

Да, похоже, вы правильно используете PDO.

Есть ли преимущество при подключении с использованием localhost по сравнению с IP-адресом сервера?

Вы имеете в виду в производстве? Рекомендуется запускать базу данных на отдельном сервере - в этом случае localhost, очевидно, не будет работать. Если загрузка невелика и вы используете базу данных и PHP-сервер на одном компьютере, то это не должно иметь значения в любом случае.

Answer 2

Хорошие вопросы, и у меня уже есть все ответы для вас (и даже ответы на вопросы, которые вы еще не задавали), просто следуйте моей статье Как подключиться к MySQL с помощью PDO .

Чтобы ответить на ваши вопросы более прямо:

- это хорошая альтернатива использованию метода die для устранения ошибок

В любом случае - нет.
Если честно, ваш нынешний подход не намного лучше старого. Код здесь негибкий, вы должны отредактировать его вручную, чтобы изменить поведение. Было бы намного лучше, если бы ваш код выдавал только ошибку, тогда как его обработка была бы определена в другом месте и легко настраивалась.

Не говоря уже о die(). Поверьте мне, сайт, который говорит вам "Не удалось подключиться!"на белом экране выглядит ужасно непрофессионально. Вы никогда не должны использовать die таким образом.

@ mkasberg прав, как правило, вы не поймаете исключение, а дадите ему всплыть там, где это будет уместно. Однако PDO-соединение является особым случаем, так как трассировка стека в случае ошибки будет содержать учетные данные БД, которые вы, вероятно, никому не хотите показывать. Чтобы предотвратить это, я предлагаю выдать совершенно новое исключение, которое будет содержать ту же информацию об ошибке, но без трассировки стека.

это правильный способ подключения?

Кроме того, что было сказано выше, мы не можем сказать точно, не увидев DSN.

Есть ли преимущество подключения с использованием localhost по сравнению с IP-адресом сервера?

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