Опасности создания иностранных ключей.nHibernate и SQL Server

Question

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

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

Например, я сталкивался с понятием «каскад наудалять".Я не думаю, что в настоящее время в базе данных есть какие-либо внешние ключи, поэтому я думаю, что это не повлияет на меня ... но как я могу убедиться, чтобы быть уверенным?

Какие еще риски мне нужны, чтобы бытьв курсе?

В некотором смысле я хотел бы просто использовать nHibernate без внешних ключей, но, насколько я вижу, это было бы невозможно?

Answer 1

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

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

Answer 2

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

Например, если бы в моей базе данных была таблица User и Comment, и я должен был удалить пользователя 1, который сделал два комментария без внешних ключей, у меня теперь было бы два комментария без владельца ! Мы, очевидно, не хотим, чтобы такая ситуация когда-либо возникала.

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

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

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

NHibernate каскады отделены от внешних ключей и являются способом NHibernate, позволяющим, например, убедиться, что все дочерние объекты удаляются при удалении родителя. Это, например, позволяет вам убедиться, что любое изменение, которое вы вносите в модель данных, не нарушает ваши отношения с внешним ключом (что приведет к исключению из базы данных и не будет применено никаких изменений). Лично я предпочитаю позаботиться об этом сам, но вам решать, хотите ли вы их использовать и как.

Answer 3

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

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

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

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