Удаление ссылочной целостности на стабильном приложении

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

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

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

источник

2013-08-04 Tappa Tappa

Что делать, если внешние ключи отмечены как 'ON DELETE CASCADE'? Теперь они выполняют критическую функцию. Почему вы хотите удалить критическую функциональность для повышения производительности? –

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

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

Из моего опыта работы с Oracle:

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

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

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

источник

2013-08-04 04:31:09

Извините, мне потребовалось некоторое время, чтобы вернуться и выбрать ответ. Действительные баллы во многих ответах, но этот ответ понравился мне больше всего. Когда текущий проект, над которым я работаю, является «полным», я попытаюсь собрать некоторые показатели о влиянии устранения ограничений внешнего ключа. –

Это может отличаться от приложения к приложению. Итак, «сколько» будет относительным термином. Прибытие на производительность при вставке или удалении записей.

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

источник

2013-08-04 03:57:05 Lokesh

Преимущества (пусть и небольшие) с незначительными минусами.

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

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

источник

2013-08-04 04:04:37

С SQL Server, по крайней мере, существует понятие доверенных ограничений. Иногда SQL Server может элиминировать объединения, если он распознает их как избыточные (например, это отношение «много-к-одному», и вы не используете какие-либо данные из этой таблицы, если внешний ключ, обеспечивающий отношение «много-к-одному», является надежным SQL Сервер не будет беспокоить выполнение соединения: он знает, что он будет соответствовать ровно по одной строке каждый раз). –

@TaSpeotIs - Я всегда считал, что если вы используете базу данных, тогда создайте таблицы/ограничения/индексы/ссылочную целостность, чтобы гарантировать, что сохраненные данные согласованы. Разумеется, база данных может свободно выполнять любые оптимизации, как она считает нужным (и люди, которые создали эти базы данных, имеют больше опыта/времени, чтобы понять это). Лучше пусть база данных сделает это, а затем попытается угадать всю компанию разработчиков. Я иду еще дальше, просто получаю доступ только к хранимым процедурам базы данных. Это гарантирует, что ваша бизнес-логика будет близка к данным. –

Ограничения ссылочной целостности могут [в некоторых базах данных, а не SQL Server] автоматически создавать индексы на этих FK; обеспечивая гораздо лучшую производительность в запросах на этих условиях.

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

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

источник

2013-08-04 04:08:00

Как можно проверить дополнительную производительность? – Lokesh

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

Могу сказать, что вы не создаете ограничения ссылочной целостности для индексов. Индексы также могут создаваться отдельно. Поэтому я не согласен, что они помогают производительности. Это дополнительная проверка, которая повлияет на ввод данных. – Lokesh

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

Вы не предоставили нам никакой информации о вашей схеме базы данных или ее использовании, поэтому я буду консервативен и оценим, что ваше преимущество в производительности может быть между ± ∞% (отдавать или принимать).

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

Удаление внешних ключей может снизить производительность с точки зрения того, что генерация запроса не может им доверять и не может использовать те же самые ярлыки, если бы им было доверено. См. Can you trust your constraints? для примера SQL Server.

Внешние ключи имеют не только последствия для производительности (например, ON DELETE CASCADE). Поэтому попытка удалить их для повышения производительности без учета того, какая функциональность, которую вы удаляете, в лучшем случае наивна.

источник

2013-08-04 04:34:55

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

ПРЕИМУЩЕСТВА:

Производительность: удаление внешних ключей вы могли бы получить выигрыш в производительности на заявления DML (INSERT, UPDATE и DELETE), но любые особенности относительно того, насколько сильно зависит от размера таблицы, вопросники, индексы, шаблоны использования (как часто обновляются строки, а также обновляется любое из полей FK, как часто вставлены и/или удаляются строки) и т. д. Хотя некоторые вопросы наилучшей практики можно утверждать «почти всегда», имеют прирост производительности, любые эффекты на производительность, связанные с любыми изменениями, могут быть определены только путем тестирования. Что касается типичных показателей производительности, связанных с удалением FK, это то, что вы вряд ли увидите, пока не попадете в относительно большое количество строк (как в миллионах или более), так и в массовых операциях.

НЕДОСТАТКИ:

Производительность: большинство людей не было бы ожидать, чтобы увидеть, что производительность может оказать негативное влияние на удаление FKs, но это вполне может случиться. Я не уверен, как работают все РСУБД, но Оптимизатор запросов в Microsoft SQL Server использует наличие FK (которые являются Enabled и Trusted), чтобы сократить некоторые операции между таблицами. Неправильное определение FK запрещает Оптимизатору обладать дополнительным пониманием, что иногда приводит к более медленным запросам.
Целостность данных: основная ответственность за базу данных заключается в обеспечении целостности данных. Производительность является вторичной (даже если она очень близка). Вы никогда не должны жертвовать основной целью для достижения более низкой приоритетности, особенно потому, что повышение производительности может быть достигнуто с помощью других методов, таких как: индексы, более/более быстрый процессор, более оперативная память и т. Д. После того, как ваши данные плохие, вы можете не сможете его исправить.Имея это в виду:
- Никогда не верьте, что приложение «стабильно» или не изменится. Если программное обеспечение не устарело, и никто не имеет исходного кода для внесения изменений, это скорее всего изменится.
- Не верьте, что вы все-таки обнаружили все ошибки в коде, независимо от того, насколько «тщательно протестированы», как вы считаете. Теперь приложение может выглядеть стабильным, но кто скажет, что проблема не будет обнаружена позже. Если в вашем приложении содержится более 10 строк кода, сомнительно, что это 100% ошибка.
- Даже если код приложения не изменяется, можете ли вы гарантировать, что никакой другой код приложения не будет написан против БД? Если это программное обеспечение, которое оставляет ваш контроль (т. Е. НЕ SaaS), можете ли вы остановить любого, кто его установил, от написания собственного кода, чтобы добавить функциональность, которую они хотят, которая не была предоставлена в вашем приложении? Бывает. И даже в SaaS-компаниях другие отделы могут попытаться написать инструменты против БД (например, Поддержка, которая должна выполнить операцию, чтобы помочь клиентам). Любой, кто рассматривает возможность удаления FK, скорее всего, не будет устанавливать разрешения/безопасность для предотвращения такой ситуации.
Возможность исправления/обновления: приложение может быть «стабильным» сейчас, но компании часто меняют направление и решения. FKs дают указания относительно правил, по которым данные хранятся. Даже если сейчас нет проблем с целостностью данных, если наступит время, когда в приложении появятся новые функции (или исправлены ошибки), не имея определенных FK, вероятность того, что ошибки будут введены из-за отсутствия «документации» «которые были бы предоставлены FK.

источник

2013-08-04 04:38:20

Я думаю, что это хороший ответ, хотя у меня есть одно несогласие: «основная ответственность за базу данных заключается в обеспечении целостности данных». неверно для многих баз данных (базовые примеры баз данных NoSQL), и было бы лучше заявлено, что «один из вариантов, сделанных при разработке многих механизмов СУБД SQL, - это подчеркнуть целостность данных» или что-то подобное. Несмотря ни на что, я не думаю, что вы никогда не будете рабом своих инструментов. Если вы хотите использовать молоток для открытия дверей, это ваш бизнес, а не молот (или ключ). Может быть, вы грабитель :) – iain

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

@iain, это проблема контекста. Вопрос заключается в том, что «FKs уже существуют, должны ли они быть удалены?», Поэтому данные и инструмент поддерживают отношения, и это почти гарантированная потеря для удаления FK. Я согласен, что отлично, что NoSQL и простые параметры, такие как Excel, не поддерживают FK, но это не имеет отношения к этому конкретному вопросу. Использование FK в РСУБД является наиболее эффективным использованием инструмента для обеспечения качественных данных и, следовательно, качественного приложения и не является ведомым инструментом. Сокращение ошибок также повышает доверие клиентов и сокращает время впустую, и все это просто хороший бизнес. –

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

источник

2013-08-04 05:45:26

Удаление ссылочной целостности на стабильном приложении

ответ

Смежные вопросы