Database design 两张桌子几乎一模一样

我正在开发一个Android应用程序和JSON web服务。双方都有一个数据库，并且都有相同的数据库模式

在客户端，订单、QAP和缺陷是服务器端数据库的副本。我无法向这些表中添加更多行

用户将有一个带有缺陷名称和四列的表单：

CRS

、

CRF

、

MA

和

MI

。在这四列上，用户将插入一些值。缺陷的名称为

缺陷。说明

，CRS、CRF、MA和MI值将成为当前电子报告的一部分

为了存储这些值（CRS、CRF、MA和MI），我使用了eReportDefect

我的问题是，用户可以添加更多的缺陷。如果我可以在Defect表中添加更多行，我不会有问题，但我不能。为了解决这个问题，我添加了UserDefect表，但我不确定这是否是一个好方法，因为我有两个表，eReportDefect和UserDefect，几乎相同

对于电子报告中填写的每个缺陷，我都有“另一个问题”，我可以有零个、一个或多个图像（表eReportDefImg和UserDefImg）

这种设计“合适”还是可以改进

我可以在主键定义中看到一些“老派”方法关于表

eReportDefect

，您的键是多余的，因为据我所知，“

defectId

”已经是唯一的，所以“

qapId

”和“

eReportId

”只会导致索引变大，从而变慢，而且这种情况下的列位置也不是最好的。在

Defect

和

DefectImg

表中正确，而在

eReportDefImg

中错误相同

好的，回到正题，如果您不能修改

eReportDefect

表，那么没有其他方法可以像创建另一个表那样

另一件事，图像。如果我理解正确，您可以修改table

eReportDefImg

，因此不需要

UserDefImg

table，甚至不需要Image table。您可以使用一个

DefectImg

表代替这三个表，该表具有：

PK image_id
FK userDefectId
FK defectId

---

如果

userDefectId

为空，则

defectId

不为空，并指向

eReportDefect

，反之亦然。这将通过

UserDefectImg

和

eReportDefImg

表节省存储和耗时的联接。如果一个图像可以容纳多个缺陷，那么实际上就需要这些功能。

在标准化方面，您的模型没有问题。您需要区分缺陷和用户缺陷。只有您可以告诉我们您的模型是否正确描述了实体之间的关系。