每当您拥有数据时，您都应该对其所代表的内容进行某种描述。有些人可能认为表名和列名就足够了。这与事实相去甚远，在我看来，在大多数情况下，您应该有随附的描述（文档）。您将需要它来进行报告、维护和进一步开发。
了解并决定要描述数据可能还不够。你需要知道如何正确地做这件事，以便它服务于一个目的（除了满足管理层或审计师对于任何文件的要求）。
让我们看一个例子。
Captain无意义的描述
我们请某些Captain描述我们的发票表，这是我们得到的结果：
发票表（之前）
| 列 | 描述 |
|---|---|
| 号码 | 发票号码 |
| 日期 | 发票日期 |
| 状态 | 发票状态 |
| 金额 | 发票金额 |
| 客户编号 | 客户号码 |
干得好, Captain Obvious! 我们没有从这些描述中了解到很多东西，是吗？它们甚至看起来像自动生成的并且不包含信息。然而，关于数据，我们不知道但应该知道的太多了。您可能至少见过一次类似的情形。
添加不明显的
Captain的工作完成了（他今天很早就完成了）。现在轮到我们了——让我们看看我们是否可以添加一些真正有用的东西。
意义
表名或列名通常不足以理解数据的用途。它甚至常常具有误导性。让我们以金额列为例。是净额还是含税？如果是订单，金额是否包括折扣？这个金额是包括退款和取消还是按照订单下单时的金额？
如您所见，该列的确切含义并不总是很明显，这是体现了描述的必要性，可以为您的组织免去大量与不正确报告和分析相关的问题。
来源、计算和默认值
数据从哪里来？是用户输入的还是计算出来的？这些计算的逻辑是什么？有默认值吗？
在我们的例子中，金额总是由用户提供，状态是工作副本，日期默认为空。如果我们有 税列，它可能是由某个触发器或存储过程自动计算的。
格式和验证
对值是否有限制，或者它们是否可以接受其数据类型的所有值？这些限制可以在任何地方定义——作为数据库约束、应用程序验证甚至业务规则。在大多数现实生活中，都有。
日期不应早于创建后的一个月，未来不应超过一周，金额应为正数，状态列仅接受预定义的值。
值列表，查找
一些列是枚举，预计包含一组有限的值，即使它们大多是没有任何约束的基本类型之一 - varchars 或 integers。在这种情况下，应用层会在某处定义有效值（标签）及其含义的列表。
制作一个方便的参考列表，列出这些值及其含义。在我们的情况下，状态列将是以下内容：'W' - 工作副本，'A' - 已批准的发票，'C' - 已取消。
外键
一些工具可以指示列是否是外键以及是哪个表的外键（Dataedo 将从 6.0 开始），但为了安全起见，让我们始终在描述中提供外键。在我们的例子中，客户编号是一个 customers 表的外键。
生命周期
预计何时会填充某个列？在插入还是在行生命周期的后期？数据是否不断更新？谁/什么更新了它？逻辑是什么？显然，数据库中的所有数据都可以随时更新，但我的意思是这里的工作流程一切照旧。
在我们的案例中，发票编号和日期是在发票获得批准时生成的。
使用
表格通常有很多列，并不是所有的列都有我们示例中显示的那样明显的目的（基本上每个人都或多或少都知道的文档中可见的字段）。通常有一些外部程序、接口或报告使用的数据字段，或者是标准打包应用程序的一部分，根本不使用。
假设客户表有一个分数字段，但没有一个开发人员知道它是什么以及它是如何计算的。事实证明，它由外部程序维护，并由营销活动策划人员使用。在文档中提到这会让管理员知道谁需要这个程序，甚至可能会阻止一些疯狂的开发人员放弃这个领域！
这些只是您在记录数据时可以考虑的几个方面。
有意义的描述
让我们应用我们刚刚学到的知识并修改我们的描述。我们可以得到这样的东西。你说呢，Captain？
发票表（后）
| 列 | 描述 |
|---|---|
| 编号 | 发票自动生成编号，每年从 1 开始。发票获得批准时生成编号。 |
| 日期 | 发票开具日期。工作副本发票为空。发票批准时自动设置为今天的日期。 |
| 状态 | 发票状态。'W' - 工作副本，'A' - 批准的发票，'C' - 取消 |
| 金额 | 以美元计的发票净额 |
| 客户编号 | 向其开具发票的客户编号。退款：客户。 |
开始记录您的表格
如果您想对表和列进行有意义的描述，您首先需要正确的工具。下载 Dataedo - 一个轻量级的 Windows 工具，使您能够在单独的存储库中描述 SQL Server、Oracle 和 MySQL 数据库的每个数据元素。您可以使用富文本、图像、长描述、添加 ER 图表并以格式良好的 HTML 或 PDF 共享。