MySQL отношения и ограничения, я должен их использовать?

Question

Я создал большую базу данных в MySQL и создал все связи между таблицами с помощью SQLYog.Это все хорошо, но на моем PHP-сайте, который я создаю, у меня часто возникают проблемы с удалением строк из базы данных, я часто сталкиваюсь с ограничениями ссылочной целостности.Затем я пытаюсь сначала удалить данные или установить значение NULL в таблицах связывания.Обычно я могу заставить это работать с некоторыми пробами и ошибками, но, кажется, нет никакого метода или надлежащего процесса, в котором я должен сделать это.Должен ли я использовать «при удалении набора NULL или каскадное удаление настроек»?Я не знаю, какой из них использовать, и опасался, что это может привести к удалению важных данных из других таблиц.

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

Answer 1

Это действительно зависит от типа данных, которые вы храните, действительно ли вам нужны данные, чтобы иметь ссылочную целостность?Для большинства «информационных систем» это просто необходимо.

Ссылаясь на ваш второй абзац:

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

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

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

прочитайте правило codd здесь

Answer 2

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

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

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

Answer 3

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

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

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