非规范化字段的命名约定答案

【问题标题】：Naming conventions for non-normalized fields非规范化字段的命名约定
【发布时间】：2011-07-23 04:55:02
【问题描述】：

当您为了性能而进行非规范化时，使用特殊的命名约定是一种常见的做法吗？

例如，假设您有一个带有 date_of_birth 列的 customer 表。然后，您可能会添加一个age_range 列，因为有时动态计算该客户的年龄范围太昂贵了。但是，人们可能会看到这变得混乱，因为不清楚哪些值是权威的，哪些是派生的。因此，也许您想将该列命名为 denormalized_age_range 或其他名称。

对这些列使用特殊的命名约定是否常见？如果是这样，是否有针对此类事物的既定命名约定？

编辑：这是另一个更现实的例子，说明非规范化何时会给您带来性能提升。这是来自一个真实的案例。假设您正在编写一个应用程序来跟踪美国所有大学的大学课程。如果您选择该学位，您需要能够为每个学位展示您毕业时获得的学分。学位的学分计算实际上非常复杂，而且需要很长时间（每个学位超过一秒）。如果您有一份比较 100 个不同学位的报告，那么动态计算学分是不切实际的。当我遇到这个问题时，我在degree 表中添加了一个credit_count 列，并预先计算了每个学位的学分。这解决了性能问题。

【问题讨论】：

+1 我也是这么想的

标签： database naming-conventions

【解决方案1】：

如果推导计算所需的所有值都已在表中，那么极不太可能通过持久化这些计算值而获得任何有意义的（甚至可衡量的）性能优势。

我意识到这并不能直接回答问题，但前提似乎是错误的：如果存在这样的条件来应用问题，那么你不需要一开始就对其进行非规范化。

【讨论】：

我使用的例子只是一个例子。关键是计算足够昂贵以证明非规范化是合理的。问题是关于命名约定，而不是关于去名称化本身。
@Jason：说真的，尝试发布一个真正是可能需要的示例。
@Adam - 这是一篇描述需要非规范化的示例的论文："Service-Oriented Data Denormalization for Scalable Web Applications"。非规范化对于高性能只读数据库也非常有用。
@Ted：我要的是操作建议的示例（用于计算值的所有数据都已经在行上），而不是非规范化的一般情况。跨度>
FWIW 我出于类似的原因来到这里。就我而言，我有数百个工作，每个工作都有成千上万的任务。我想生成一份工作的快速列表以及它们是否完整。要确定作业是否完成，我需要检查 TaskStatus 的所有子任务。这需要相当长的时间，所以我将在Job 中添加一个IsComplete，并允许最后一个Task 进行设置。

【解决方案2】：

我看到列名在表示这种值时使用“派生”一词。我还没有看到其他类型的非规范化的通用样式指南。

我应该补充一点，在我所见过的每种情况下，派生值始终被认为是派生数据的次要数据。

【讨论】：

【解决方案3】：

在某些编程语言中，例如Java，带有_ 前缀的变量名用于私有方法或变量。私有意味着它不应该被类外的任何方法修改/调用。

我想知道在命名派生数据库列时是否可以借用这个约定。

在 Postgres 中，列名可以以_ 开头，例如_average_product_price。

它可以传达你可以阅读本专栏的意思，但不要写它，因为它是派生的。

【讨论】：

【解决方案4】：

我现在处于同样的情况，正在设计一个可以从中心值的非规范化中受益的数据库模式。例如，表分区要求表中存在分区键。因此，即使可以通过遵循某些级别的外键来检索数据，我也需要大多数表中的数据。

也许后缀“copy”可以用于此。因为毕竟，数据只是存储主要数据的其他位置的副本。由于它是一个词，它可以与所有命名约定一起使用，例如可以映射到 SQL 蛇形大小写的 .NET PascalCase，例如。 G。 CompanyIdCopy 和 company_id_copy。这是一个简短的单词，所以你不必写太多。而且它不是缩写，因此您不必拼写或想知道它的含义。 ;-)

我也可以想到后缀“缓存”或“缓存”，但缓存通常是按需填充并在一段时间后失效，这通常不是非规范化列的情况。这些数据应该始终存在，并且永远不会过时或丢失。

“派生”一词比“复制”稍长。我知道一个特殊的 DBMS，一个昂贵的，列名限制为 30 个字符，所以这可能是个问题。

【讨论】：