Question

I’m developing an Android application and JSON web services. Both sides will have a database, and both of them will have the same database schema.

On client side, Order, QAP and Defect are a copy from server side database. I can’t add more rows to those tables.

User will have a form with defect name and four columns: CRS, CRF, MA and MI. On these four columns user will insert some values. Defect’s name is Defect.description, and CRS, CRF, MA and MI values will be part of current E-Report.

To store these values (CRS, CRF, MA and MI) I use eReportDefect.

My problem is that user can add more defects. If I could add more rows on Defect table, I won’t have a problem, but I can’t. To solve it I have added UserDefect table but I’m not sure if this is a good approach because I have two tables, eReportDefect and UserDefect, almost identical.

And I have “another problem” for every Defect filled in an EReport, I could have zero, one or more images (tables eReportDefImg and UserDefImg).

Is this design “OK” or it could be improved?

Answer 1

I can see some “old school” approach in primary key definition. 😉 Regarding the table eReportDefect your key is redundant, because as I understand “defectId” is already unique, so “qapId” and “eReportId” will only cause an index to be bigger thus slower – also the column positions in that case aren’t the best. It is correct within Defect and DefectImg tables, while the same mistake is within eReportDefImg.

Ok, back to the point, if you can’t modify eReportDefect table there is no other way like create another table.

Another thing, images. If I understand correctly you are able to modify table eReportDefImg, so there is no need for UserDefImg table and even for Image table. Instead of those three tables you can use one DefectImg table having:

PK image_id
FK userDefectId
FK defectId

If userDefectId IS NULL, then defectId IS NOT NULL and points to eReportDefect, and the other way around. This will save you storage and time consuming joins through UserDefectImg and eReportDefImg table. Those would be actually needed if one image could fit into more than one defects.