Ссылочная целостность в реляционном хранилище данных. Стоит ли оно того? а какие есть альтернативы?

Question

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

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

Есть мысли?

Заранее спасибо.

Answer 1

Во-первых, я бы не стал создавать хранилище данных, которое (физически) соответствовало бы реляционной схеме.Является ли предлагаемое хранилище данных полностью нормализованным или слово «реляционный» в вопросе просто указывает, что оно будет встроено в базу данных SQL?

Answer 2

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

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

Answer 3

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

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

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

Надеюсь, это поможет!