Имеет ли смысл когда-либо применять приложение для обеспечения целостности базы данных вместо использования внешних ключей, проверки ограничений и т. Д.?
Насколько можно повысить производительность, если не обеспечить целостность базы данных с помощью внутренних инструментов базы данных?
Ответы:
По правде говоря, вы не только не увидите значительных потерь производительности из-за ограничений внешнего ключа в базе данных, но вы также увидите улучшения производительности. Оптимизатор запросов SQL Server построен на основе концепции первичных и внешних ключей, а также других типов ограничений данных. Если они установлены и применяются, оптимизатор может использовать их для повышения производительности. Вот сообщение в блоге с простым примером , демонстрирующим его в действии.
Если вы находитесь в крайнем случае, когда у вас действительно больше вставок, чем чтений (а для обновлений и удалений требуются чтения, поэтому они обычно заканчиваются добавлением к количеству считываний), тогда может иметь смысл удалить ограничения из данных для производительности, возможно, , Но поскольку подавляющее большинство баз данных ориентировано на чтение, вы жертвуете производительностью, а не повышаете ее.
И ни в одном из них не упоминается тот факт, что целостность данных лучше обрабатывается в базе данных, поскольку вам нужно создать ее только один раз, когда, как будто вы делаете всю работу в коде, вам, возможно, придется делать это несколько раз для нескольких приложений (если вы не проектируете ваш уровень доступа к данным тщательно и требует, чтобы каждое приложение обращалось к БД, чтобы пройти через тот же слой).
Если вы используете систему реляционных баз данных, я говорю, почему бы не использовать ее на самом деле. Если вам не нужны реляционные данные, используйте Hadoop или что-то еще.
Многие разработчики приложений так считают.
Когда вы испытываете желание делегировать целостность данных коду приложения, подумайте: «Каждый программист и каждое приложение, которое обращается к этой базе данных с настоящего момента до конца времени, должно каждый раз получать ее совершенно правильно».
Каковы шансы?
Даже если есть какой-либо выигрыш в производительности, он незначителен по сравнению с возвратом ссылочной целостности и обобщенной целостности данных.
Давно прошли те времена, когда база данных была тупым хранилищем данных. Используйте всю мощь, предлагаемую СУБД.
Повышение производительности - это еще не все, особенно в таких небольших масштабах, как этот. Но когда вы обнаружите, что у вас есть предполагаемая связь по внешнему ключу, которую ваше приложение должно обеспечивать, и оказывается, что это не первичный ключ в ссылочной таблице, тогда вы будете очень мало заботиться о повышении производительности (если таковые имеются, я могу не говорите об особенностях этого).
Обычной практикой является удаление ограничений (внешних ключей, CHECK и т. Д.) И индексов, если вы выполняете достаточно большую загрузку данных, и затем повторно включите / внедрите ограничения и индексы. Эта проверка имеет временные затраты. Это предполагает, что вы не можете использовать специфический синтаксис массовой загрузки базы данных (включая минимизацию журналирования).
Невозможно сказать, сколько ожидаемого увеличения производительности - каждая ситуация уникальна (типы данных, дизайн и т. Д.). Единственный способ по-настоящему узнать это проверить.
Есть несколько раз, когда ограничения мешают:
Когда вам нужно использовать Single Table Inheritance (STI). Представьте, что вы продаете как частным лицам, так и организациям. Вам понадобится одна таблица «Вечеринка», строка которой будет индивидуальной или организационной. STI означает, что вам нужны некоторые пустые поля, которые не должны быть нулевыми. Наследование таблиц классов решает эту проблему, но для некоторых ORM это сложнее. Например, ActiveRecord в Ruby поддерживает только STI.
Когда вам нужно поддерживать черновые версии сущностей, это может быть не совсем корректно. Вы можете сохранить черновик как json, но тогда будет сложнее повторно использовать тот же идентификатор на клиенте - представьте, что он был сохранен с id = 5, отредактирован, чтобы быть недействительным, и автоматически сохранен как draftid = 99. В этом случае все ваши поля, вероятно, должны быть обнуляемыми.