创建数据库时 - 是否建议为我可以根据其他字段计算的数据创建一列？答案

【问题标题】：When creating a database - Is it advisable to create a column for data I can calculate based on other fields?创建数据库时 - 是否建议为我可以根据其他字段计算的数据创建一列？
【发布时间】：2016-02-18 18:10:28
【问题描述】：

我正在为一位律师构建一个应用程序，他可以在其中创建一个客户组合。在这个投资组合中，有投资组合的ID、创建日期、客户姓名、电话等。

除了所有这些字段之外，还有另一个字段：“投资组合名称”。此字段包含来自其他字段的有关客户端的一些信息，格式为格式化文本。

所以，例如，如果：

ID = 271
client_name = "John Doe"
创作日期 = 18/02/2016

portfolio_name 将是 271/John Doe/18022016。

现在，既然 portifolio_name 并没有真正包含新数据，而只是来自其他字段的格式化数据，那么它真的应该作为列存在于数据库表中吗？是不是数据重复？

【问题讨论】：

这是数据重复，但在某些情况下可以接受级别或冗余。
视情况而定。如果您的数据库支持，至少我会将其设为表中的实际计算列。如果他更改为无法计算的其他格式，您将需要进行大量返工。
您能回复一下吗？所以其他人可以更轻松地从您的回答中受益？

标签： database field

【解决方案1】：

这是违反 1NF 的教科书，通常应该避免。在某些情况下这是可以接受的——例如，计算值很难或很耗时地获得。但是，由于字符串连接非常简单（您甚至可以在查询中直接完成，而无需定义任何伪字段）除非该字段仅包含初始默认值并且客户端具有以后可以自定义它。否则，它将最终变得不一致。例如，当客户名称更改时会发生什么？

【讨论】：

SQL 计算列在不破坏 1NF 的情况下解决了这个问题。
当然，这是一个可行的解决方案，假设您的数据库支持它们。但是，请注意，计算列不是标准 SQL，因此您引入了对特定数据库引擎的依赖，仅用于简单的字符串连接。此外，计算将被视为业务逻辑，并且由于它将内置到您的架构而不是您的应用程序代码中，因此如果它发生更改，它将不会（容易）受到源代码控制。

【解决方案2】：

这取决于表的大小和查询表的方式。

如果表格很大，您可以为计算字段创建一列。方便查询。

如果表小可以在查询中计算

【讨论】：

我认为这是一张大桌子。上千条记录……但是即使查询有点复杂，重复数据也不是很糟糕吗？
几千条记录不大。 :)

【解决方案3】：

大多数数据库引擎都允许您为此目的创建计算列。根据引擎以及您设置计算列的方式，它可能会或可能不会保存到磁盘，但可以保证它始终是最新的。好处是您可以将其视为只读列。

https://technet.microsoft.com/en-us/library/ms191250%28v=sql.105%29.aspx

【讨论】：