正在考虑为我的数据库设计一个新的表格。我在将最终计算存储在表列中，或者在我计划创建的视图中计算它们之间徘徊。例如，如果您要将值10存储在一列中，而将5存储在另一列中，并且您希望在另一列中存储（10/5），那么您认为将5存储在其自己的列中是否更好，或者计算它在计划中的视图？
该表每天将包含大约400,000条记录，可能一年左右。即使我可以使用简单的数据类型来降低存储成本，我仍然需要为每条记录维护另外4个字节的数据*我可能拥有的同一行中有多少计算记录。
我将在几天的数据中查询计算值。我仍然想要速度，但也想要一个更小的数据库，更容易维护表，以及视图的灵活性。
您有什么看法和想法？
答案 0 :(得分：1)
我将查询计算值......
我用什么方式？
1 对于CPU的小幅增加，您将降低存储要求，从而提高缓存效率，从而降低I / O，这往往是最重要的性能大多数OLTP工作负载的瓶颈。当计算成本很高时，缓存结果是合理的，但是简单的除法与该阈值相差甚远。
2 在表格中作为普通字段，或作为持久计算列或在物化/索引视图中。
答案 1 :(得分：1)
数据完整性是最重要的。
在视图中计算结果可确保为您提供最新的答案。权衡是SELECT语句的运行时性能，尤其是在WHERE子句中使用结果时。根据我的经验，如果在WHERE子句中使用计算结果很少。通过计算，我的意思不仅是算术，还有字符串和子串提取和连接，校验和计算等。
将计算结果存储在基表中可以获得最佳的SELECT性能。权衡是数据完整性。如果你可以编写一个CHECK（）约束来保证结果总是正确的，你应该这样做。但是，如果不使用用户定义的函数，有时无法表达复杂计算的CHECK（）约束，并且并非所有平台都支持CHECK（）约束中的用户定义函数。
如果无法编写CHECK（）约束，则仍需要某种类过程来定期检查数据是否存在错误。在最糟糕的情况下，您可以在需求较低的情况下每天或每周运行一次报告。
物化视图可能会为您提供两全其美的优势 - 可以作为可搜索WHERE子句的目标的计算，并且始终保证是正确的。 （SQL Server等效项称为索引视图。）权衡是存储空间和在更新基表后保持物化视图及其索引最新所需的CPU周期。 / p>
通常，我会先尝试一下。但在你的特殊情况下 - 365天每天400k行 - 我想我会首先尝试物化视图。它无论出于何种原因都无法正常工作，您可以将其替换为基表中的列，删除实例化视图，并创建具有相同名称的新视图。 （逻辑数据独立性。）
答案 2 :(得分：0)
如果您有开发环境，我建议您测试这两种方法，并选择能够提供每项工作/维护成本最佳性能的方法。即使表存储〜400k记录，取决于您访问该数据的方式，一种方法可能更有意义。