我有Customer，Purchase等表，有时会与他们有关联的文件，文件我的意思是某个地方的某个文件（比如扫描的驾驶执照或其他东西）
我们不能让应用程序将这些文档直接上传到数据库中，因此我有一个uniqueidentifier列（我应该使用文件哈希吗？）
我的问题：
将来我们可能会有更多与表相关联的文档，所以我想添加额外的字段，如：
客户
+ DriversLicenseDoc
+ Document1 //面向未来的 + Document2 //未来使用
所以将来如果他们确定他们想要另一个文档，我将只需更新我的实体框架模型并重命名模型中的列，数据库就不必更改了？
这是一般的吗？有更好的想法吗？我看到的缺点是我将不得不将所有这些未来值保持为可空？也许这不是一个缺点？ 还想听听有关如何在部署后如何应对数据库架构更改的想法？
答案 0 :(得分：4)
不，这实际上是一个非常糟糕的主意。您可以预见正确使用，在这种情况下按照预期添加它们，或者您只是猜测可能发生的情况，在这种情况下您应该等到您知道。
部署后处理架构更改的方法是在部署后更改架构（以及任何相关代码）。你应该看看首字母缩略词“YAGNI”。在我的意见中，任何不需要立即进行的努力都应被视为对可能永远不需要的事情所做的努力。换句话说，浪费了精力。
如果您可能存在未知数量的文档，那么这是从customers表到文档表的简单的一对多关系，表中的每个文档都包含文档类型和文档有效负载，如下所示：
customers:
custid primary key
<all other customer data>
documents:
docid primary key
custid references customers(custid)
<all other document data>
这样，每个客户可以根据需要拥有尽可能多的文档。