如何设计列数可能随时间增加的数据库？答案

【问题标题】：how to design for database where column number may increase by time?如何设计列数可能随时间增加的数据库？
【发布时间】：2016-07-20 02:38:37
【问题描述】：

我正在尝试为我的应用和网络服务设计一个数据库，假设 View 属性的表是这样的：

所以View有prop_id, x, y, width, height, bg_color, txt_color

一段时间后，我需要在此表中添加一个新列，例如：

text_size, has_shadow ...等

属性的类型是动态的，属性的数量也是动态的。

那么我们如何设计这种可扩展的数据库呢？

【问题讨论】：

【解决方案1】：

当您需要新属性时，您可以在表格中添加一列。

我相信人们会建议您尝试使用 EAV（实体-属性-值）模型来适应这些类型的数据库更改，但这是一个巨大的错误，IMO。需要这种反模式的情况非常、非常少，而这不是其中之一。

如果您的数据库现在需要跟踪“text_size”，那么您的应用程序可能需要更改以处理此文本大小。您将不得不按原样更改您的应用程序和/或数据库，因此使用 EAV 模型您什么都不买（除了头痛）。

如果您使用 Google EAV，那么您可以找到更多关于它的信息以及为什么它是一个坏主意，但简而言之，它使查询数据库变得更加困难和性能降低，并使维护更加困难，而不是更容易。

【讨论】：

所以每次出现新属性时，我应该向数据库添加新列吗？是不是也很昂贵的操作？
您需要定义“昂贵”。贵在什么方面？向表中添加列只是元数据更改，几乎是瞬时的。您希望多久添加一次新属性？如果您添加一个属性，您是否已经需要确保您的应用程序可以容纳它？
我认为添加属性会很昂贵，因为它将被添加并插入为 0 或整个表的默认值。所以我在编写应用程序时有了这个想法，客户开始添加新东西，我想如果他在我们发布后问怎么办......这就是我问这个问题的原因
如果您有需要传播到表中所有行的默认值并且该表非常很大，那么有一个成本。因此，您在晚上运行更新，运行需要 20 秒（或任何时间）。如果您担心在开发过程中需求发生变化，那是开发的一部分——您不必为了处理这种情况而扭曲您的数据库。添加列并继续。使用 EAV 在短期内不会让事情变得更容易，从长远来看会使事情变得更加困难。