Есть ли причина не определять ключи, иностранные или другие - PullRequest
2 голосов
/ 25 сентября 2019

Я беру некоторый код, который опирается на коллекцию таблиц Oracle, у которых нет явных ключей (первичных, потенциальных или внешних), определенных для Oracle явно, но тем не менее используемых в качестве ключей.Есть ли веская причина не определять их, даже если они отключены?

Таблицы определены, и есть SQL для выполнения чего-то вроде select * from table1 inner join table2 на table1.somekey.Поля существуют и запрос выполняется (медленно), но ограничения не определены.Иногда столбцы определяются как не нулевые и не уникальные, но это наиболее близко к ключу, который они имеют.SQL нигде не определяет ограничения внешнего ключа.Я мог бы определить их сам, и это сработало бы, но мне интересно, есть ли причины не определять их, даже если они отключены.Прямо сейчас, единственный способ определить отношение - это найти запросы на выборку где-нибудь в базе кода и посмотреть, какие соединения действительно сделаны.

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

Спасибо от Вудсмена.

Ответы [ 2 ]

3 голосов
/ 25 сентября 2019

В общем, нет особых оснований не определять ограничения.

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

Кроме того, важность приложений со временем затухает;приложения устаревают.Данные, которыми они управляли, сохраняются гораздо дольше.Он по-прежнему полезен и полезен (я говорю здесь по-настоящему $) легко через 10 лет (и более) после того, как приложения были сняты с производства.Данные должны храниться в безопасности.

Моя цель в этом вопросе состоит в том, чтобы выяснить, есть ли какая-то "стоимость" для определения ограничения

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

Итак, вкратце, в 99,99% случаев у вас должны быть ограничения для защиты ваших данных.

1 голос
/ 27 сентября 2019

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

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

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...