Насколько важны ограничения типа NOT NULL и FOREIGN KEY, если я всегда буду контролировать ввод своей базы данных с помощью PHP?

Question

Я пытаюсь создать столбец в таблице, который является внешним ключом, но в MySQL это сложнее, чем должно быть. Это потребовало бы от меня возврата и внесения определенных изменений в уже используемую таблицу. Поэтому мне интересно, Насколько необходимо, чтобы MySQL был уверен, что определенное значение подходит? Разве я не могу сделать это с помощью языка, такого как PHP, который я использую для доступа к этой базе данных в любом случае ?

Аналогично с NOT NULL. Если я получаю доступ к этой базе данных только через PHP, могу ли я просто заставить PHP гарантировать, что нулевое значение не будет введено?

Почему я должен использовать MySQL для принудительного применения этих ограничений, когда я мог просто сделать это с помощью PHP?

---

Я понимаю, что NOT NULL - это очень глупая часть, которую можно игнорировать по вышеуказанным причинам. Но MySQL не применяет внешние ключи без серьезного манипулирования.

По вашему мнению, было бы все еще плохо использовать «поддельные» внешние ключи и просто проверять, соответствуют ли вводимые значения в других таблицах с PHP?

Answer 1

Самая важная вещь в использовании NOT NULL для меня - это больше часть документации. Когда я возвращаюсь к проекту через несколько месяцев, я забываю, в каких столбцах допустимо иметь значения NULL. Если в столбце указано NOT NULL, то я знаю, что мне никогда не придется иметь дело с потенциальными значениями NULL из него. И если он допускает нулевое значение, то я точно знаю, что должен иметь с ними дело.

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

Answer 2

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

Затем реализуйте лучшие значения и ограничения по умолчанию на уровне приложения. Если вам технически запрещен ( доступ к API-интерфейсам, внешним по отношению к базе данных ) от реализации ограничения или создания значения по умолчанию на уровне базы данных, то приложение необходимо для этого сделать. Это приведет к значению лучше по умолчанию. Однако ошибка или общий сбой приложения не приведет к сохранению неприемлемых данных.

Answer 3

Боюсь, это религиозная тема.

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

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

Как примечание, настройка MySQL для поддержки ограничений внешнего ключа - процесс, потому что вам нужно перейти на InnoDB . Если вы сделаете просто , вы сможете вернуть себе большую производительность, установив innodb_flush_log_at_tx_commit в 1. Но, вероятно, было бы лучше, если бы вы вместо этого могли реорганизовать свой сайт, чтобы учитывать транзакции. Тогда вы получаете два преимущества InnoDB.

Answer 4

Я высоко ценю ваш вопрос, так как я глубоко убежден, что правила по умолчанию должны быть реализованы на стороне кода, а не на стороне базы данных, и это по очень простой причине: когда пользователи являются теми, кто инициирует Изменения базы данных (INSERTS, SELECTS и UPDATES), эти изменения должны интегрировать все бизнес-правила, а значения по умолчанию в основном являются бизнес-правилами:

• Нет счета без номера счета
• Строка счета-фактуры отсутствует без количества, а ноль или ноль недопустимы
• Нет входящей почты без даты получения
• и т.д.

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

За последние 2 года никто в команде никогда не думал об объявлении значения по умолчанию в таблице. Я предполагаю, что наш младший стажер даже не знает о чем-то, что называется "значением по умолчанию".

РЕДАКТИРОВАТЬ: перечитывая некоторые ответы здесь, мой последний комментарий: сделайте это с любой стороны, будь то БД или код, но сделайте свой выбор и сделайте это только с одной стороны! Нет ничего более опасного, чем иметь такие элементы управления с обеих сторон, потому что в конечном итоге (1) вы никогда не узнаете, действительно ли обе стороны реализуют одно и то же правило, а это означает, что (2) проверка правил будет означать проверку обеих сторон, что может реально стать беспорядком! Наихудшая ситуация, конечно, когда одна часть работы выполняется на стороне базы данных (т.е. правила, которые были определены при создании базы данных), а другая часть (то есть новые идентифицированные правила) выполняется на стороне клиента ... кошмар ....

Answer 5

1. Я не думаю, что вы можете быть уверены, что ваша база данных будет доступна только PHP и, если да, разработчиками, которые будут использовать ее для соблюдения этих ограничений для всего жизненного цикла вашей базы данных.

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

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

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