我正在设计一个在表之间具有许多复杂完整性规则的关系数据库。我正在考虑的方法是定义最基本的表，并编写视图以表示从基本表中产生的更高层次的概念。
例如，假设有一个银行帐户数据库，我定义了一个具体的transaction表，保留了一个帐户的存款和取款，以及一个名为balance的视图，该视图汇总了每个帐户的所有存款和取款。还有一个名为liability的具体表，用于注册每个帐户中冻结的金额，因此视图avaliable_balance是balance所给的余额减去该帐户所有冻结资金的总和在表liability中。随着它的发展，它变得越来越复杂。
随着数据库的增长，我担心一些简单的事情，例如发现客户可以花多少钱会产生一个过于复杂和昂贵的查询。替代方法是：
UPDATE，INSERT和DELETE触发器自动更新。但是，这很容易出错，开发时间很长，而且感觉很不对劲，因为可以从视图的定义中“轻松”地推断出关系和更新规则，并且似乎应该自动完成。这样的数据库增长时，我会遇到性能问题吗？如果是，我该如何解决？在性能方面，哪种方法最好？我没有其他选择吗？
答案 0 :(得分：0)
这个问题太笼统了，我只能给出一个非常笼统的答案。在另一天，我可能会投票赞成“范围太广”。
视图可以是好事也可以是坏事。它们有益于
从实际物理数据模型中提取接口
允许用户仅查看表中数据的某些部分
您的用例是第一个。
定义观点时要运用品味和歧视。这是两个准则：
不要将视图层次结构嵌套得太深。通常两个以上的级别太多了。深入的视图层次使模型难以理解，并且调试非常困难。
永远不要忘记视图不是表。它可能仅在某些查询中表现良好，例如在某些附加WHERE条件下。
您能做的最好的事情是在设计时确定要对数据库运行哪种查询，尤其是频繁查询。然后，您可以计划视图，以便它们在这些查询中表现良好。
使用物化视图和其他技术来保留冗余数据，除非您对性能有任何要求。通常，一个好的设计就足够了。