Поддержание комплексной логической целостности таблиц

Question

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

Например, представьте себе базу данных банковского счета, я определяю конкретнуюtransaction таблица, в которой хранятся депозиты и снятия со счета, и представление под названием balance, суммирующее все депозиты и снятие средств с каждого счета.Существует также конкретная таблица с именем liability, в которой регистрируются суммы, заблокированные на каждом счете, поэтому представление avaliable_balance представляет собой баланс, заданный balance минус сумма всех заблокированных денег для счета в таблице liability.По мере того, как это происходит, оно становится все более сложным.

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

• Материализованные представления, но, насколько я понимаю, они не обновляются автоматически, и их обновление является дорогостоящей операцией, которую невозможно выполнить при каждом изменении таблицы.
• Конкретные таблицы для представлений, обновляются автоматически только с помощью триггеров UPDATE, INSERT и DELETE на основных таблицах.Но это подвержено ошибкам, дорого во время разработки и просто кажется неправильным, так как отношения и правила обновления могут быть «легко» выведены из определений представлений, и кажется, что это должно быть сделано автоматически.

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

Answer 1

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

Представления могут быть как хорошими, так и плохими.Они хороши для

• абстрагирования интерфейса от реальной физической модели данных

• , позволяющего пользователю видеть только некоторые части данных втаблица

Ваш вариант использования является первым.

Используйте вкус и дискриминацию при определении своих взглядов.Вот два правила:

• Не вкладывайте иерархию представлений слишком глубоко.Больше двух уровней обычно слишком много.Глубокая иерархия представлений делает модель непонятной и делает отладку очень сложной.

• Никогда не забывайте, что представление не является таблицей.Он может работать хорошо только в определенных запросах, например, при определенных дополнительных WHERE условиях.

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

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