0

我有像等这样的表格Customer，这些表格Purchase有时与它们相关联，文件是指某处的一些文件（如扫描的驾驶执照或其他东西）

我们不能让应用程序将这些文档直接上传到数据库中，所以我有一个 uniqueidentifier 列用于这些（我应该有一个文件哈希吗？）

我的问题：
将来我们可能会有更多与表格相关联的文档，所以我正在考虑添加额外的字段，例如：

Customer
+DriversLicenseDoc
+Document1//供
将来使用 +Document2 //将来使用

因此，将来如果他们确实决定需要另一个文档，我只需要更新我的实体框架模型并重命名模型中的列，数据库就不必更改了吗？

这是它的一般做法吗？有更好的想法吗？我看到的缺点是我必须让所有这些未来的值都可以为空？也许那不是缺点？
还想听听关于部署后您通常如何应对数据库模式变化的想法？

4

1 回答 1

4

不，这实际上是一个非常糟糕的主意。要么您预见到正确的使用，在这种情况下按原样添加它们，或者您只是在猜测在这种情况下可能会发生什么，您应该等到您知道为止。

部署后处理架构更改的方法是在部署后更改架构（以及任何相关代码）。您应该查看首字母缩略词“YAGNI”。在我看来，任何不是立即需要的努力都应该被视为为可能永远不需要的事情所做的努力。换句话说，白费力气。

如果您可能存在未知数量的文档，这是从客户表到文档表的简单一对多关系，表中的每个文档都带有文档类型和文档有效负载，例如：

customers:
    custid  primary key
    <all other customer data>
documents:
    docid primary key
    custid references customers(custid)
    <all other document data>

这样一来，每个客户都可以拥有任意数量的文档，以及所需的任意类型。

于 2010-12-19T12:06:11.153 回答