Знание того, где и когда обеспечивать уникальность ваших данных

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

Давайте попробуем разобраться в этом вместе.

Уровень приложения и уровень базы данных

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

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

| | Уровень приложения | Уровень базы данных | |----|----|----| | Плюсы | * Миграция не требуется | * Форсировать ограничения независимо от того, какой клиент | | | | * Обрабатывает индексы за кулисами | | | | * Центральное место для обеспечения соблюдения всех ваших правил | | Минусы | Дополнительная логика для проверки уникальности | |

Предполагая, что ваш случай покрывается выбранной вами БД, я определенно рекомендую использовать вашу БД для обеспечения соблюдения ваших ограничений. И все, что вам нужно сделать, это обработать сбой на уровне вашего приложения, поскольку большинство клиентов БД возвращают коды ошибок, подобные приведенным ниже:

if ( err && err.code !== 11000 ) {
    console.log(err);
    res.send('duplicate record, u need to focus user!!!');
    return;
  }

Конечно, я бы также порекомендовал оборачивать ваши ошибки, но это тема позже.

Код статуса

Должен ли код состояния быть другим, кроме 4xx? Ну хорошо, 4xx означает, что пользователю нужно выполнить какое-то действие или, другими словами, это вина пользователя в том, что это произошло, поэтому должно быть 4xx.

Какой из 4xx? Теперь вам может быть интересно, почему бы не использовать 400 вместо 409. Дело в том, что ваш код состояния должен быть чистым и фактически отражать состояние, поэтому, если вы использовали код 400 для всего, это означает, что FE должен выполнять дополнительную работу с вашими ответами об ошибках. , то почему бы не упростить работу с вашими пользователями API номер 1 и просто вернуть 409

Заключение

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

Также опубликовано здесь .