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

Question

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

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

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

---

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

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

Answer 1

Вы собираетесь совершать ошибки с PHP, 100% гарантировано. PHP процедурный. То, что вы хотите, это декларативные ограничения. Вы хотите сказать весь стек: «Это ограничения на данные, и эти ограничения не могут быть нарушены». Вам не нужно много использовать «Шаг 1 ... Шаг 2 ... Шаг 3 ... Шаг 432 ...», как ваш метод принудительного ограничения данных, потому что

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

На самом деле должен быть сформулирован вопрос: «Почему я должен использовать PHP для обеспечения соблюдения этих ограничений, когда я могу просто сделать это с MySQL?»

Answer 2

Вы не можете "просто" сделать это с PHP по той же причине, по которой программисты "просто" не могут писать код без ошибок. Это сложнее, чем вы думаете. Особенно, если вы думаете, что это не так сложно.

Answer 3

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

Поскольку реальные сценарии всегда содержат некоторую неопределенность, хорошо, чтобы сервер БД следил за целостностью ваших данных.

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

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

Answer 4

Я обычно за объявление об ограничениях в базе данных. Аргументы для ограничений:

• Декларативный код легче создать без ошибок, чем императивный код. Ограничения применяются, даже если код приложения содержит ошибки.
• Поддерживает принцип «Не повторяйся», если у вас есть несколько приложений или модулей кода, обращающихся к одной и той же базе данных, и вам нужно, чтобы бизнес-правила применялись единообразно. Если вам нужно изменить ограничение, вы можете сделать это в одном месте, даже если у вас много приложений.
• Обеспечивает целостность данных, даже когда люди пытаются обойти приложение, используя специальные инструменты запросов для работы с базой данных.
• Обеспечивает согласованность , что означает, что вы всегда можете быть уверены, что данные находятся в допустимом состоянии до и после любого обновления данных. Если вы не используете ограничения, вам может потребоваться периодически выполнять запросы, чтобы проверить наличие неработающих ссылок и очистить их.
• Вы можете моделировать каскадное обновление / удаление легко с ограничениями. Делать то же самое в коде приложения сложно и неэффективно, нельзя применять изменения атомарно (хотя рекомендуется использовать изоляцию транзакций) и подвержено ошибкам.
• Ограничения помогают базам данных быть более самодокументируемыми, как помогают имена столбцов и типы данных SQL.

Аргументы против ограничений:

• Более сложные бизнес-правила не могут быть смоделированы с помощью декларативных ограничений, поэтому вы все равно должны реализовать их в пространстве приложения. Учитывая это, почему бы не реализовать все бизнес-правила в одном месте (в вашем приложении) и на одном языке? Это облегчает отладку, тестирование и отслеживание изменений кода.
• Ограничения часто включают в себя индексы, которые влекут за собой определенные накладные расходы во время вставок / обновлений. С другой стороны, даже если вы не объявляете ограничение, вам все равно, вероятно, нужен индекс, потому что столбец может часто использоваться в критериях поиска или в условиях соединения.
• Ограничения могут усложнить ваши попытки «убрать» ошибки в данных.
• В вашем текущем проекте несовместимость MyISAM и InnoDB по отношению к ссылочным ограничениям вызывает некоторое горе.

Answer 5

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

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

Answer 6

Они довольно важны. Вы не хотите определять свою модель полностью через PHP. Что если в вашем PHP-коде есть ошибка? Вы могли бы легко иметь нулевые столбцы, где ваши бизнес-правила утверждают, что вы не должны. Определив его на уровне базы данных, вы, по крайней мере, получите эту проверку бесплатно. Вы будете действительно ненавидеть это, когда в вашем PHP есть ошибки или если какой-либо другой инструмент когда-либо использует вашу базу данных. Ты просто просишь проблемы, ИМХО.

Имейте в виду, это очень короткая версия истории.

Answer 7

Даже если ваш PHP-код совершенно не содержит ошибок, он может прекратить выполнение промежуточного сценария (нехватка памяти, ошибка в какой-либо библиотеке и т. Д.), Оставив наполовину вставленный материал в базу данных, поэтому важно использовать InnoDB и сделки.

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

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

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

Answer 8

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

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

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

Моя рекомендация - выбрать другую СУБД.

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

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

На ваш вопрос NOT NULL ... Очевидные требования к полям данных являются хорошей отправной точкой. Вот несколько вещей, которые следует учитывать при определении обнуляемости столбцов.

Это дает гарантию, которая может быть очень полезна при написании запросов. Различные объединения могут использовать условия NULL, чтобы показать несоответствие строки таблицы отдельно от значения NULL, которое нельзя предположить, если условие допускает пустые значения. (Если разрешены значения NULL, совпадение может означать, что строка не соответствует или строка соответствует, но значение столбца равно нулю.)

Использование NOT NULL также помогает определить правила для простых запросов, соответствующих значениям. Поскольку вы не можете сказать «КОГДА value1 = value2», если и value1, и value2 равны NULL, результат оценки по-прежнему ложен.

Answer 9

Используйте базу данных для структурной целостности данных и используйте уровень BR для остальных. И ловить ошибки как можно раньше. Они работают вместе.

Если повезет, когда ваш код станет зрелым, у вас не возникнет ошибок RI в базе данных; и вы можете с гордостью объявить себя первым.

Answer 10

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

Имейте в виду, что ошибки, от которых вы спасете себя, могут быть довольно неприятными. Найти и исправить саму ошибку может быть нетрудно; неприятная часть в том, что как только вы исправите ошибку, у вас останется куча ошибочных данных, которые могут даже не быть спасены.

Я бы даже не подошел к этой проблеме с точки зрения «ну, что-то кроме PHP может когда-нибудь получить доступ к вашим данным». Это правда, но еще важнее, на мой взгляд, головные боли, время (деньги) и потеря данных, которые вы можете сэкономить, просто добавив несколько простых ограничений.