The tables are very closely tied to the file structure, which will negatively impact extensibility. This will be an issue further down the line, as we will want to continue to add new functionality to qcdb. One possible option (as per Mary), is to format all of the information inside the different metrics tables as .json entries that will be inserted into a column so that each individual table doesn't need to be parsed. New column IDs would be the unique primary key (SRA experiment, SRA project, SE, PE1, or PE2), QC program, QC metric, json data entry. In the end there will be 3 tables -- the metrics, the sample metadata, and a third table indicating which programs are supported by the DB and generally the types of inputs and outputs of each QC metric and other specific vocabulary (like, is it a variant calling experiment or RNAseq experiment, etc.).
The tables are very closely tied to the file structure, which will negatively impact extensibility. This will be an issue further down the line, as we will want to continue to add new functionality to qcdb. One possible option (as per Mary), is to format all of the information inside the different metrics tables as .json entries that will be inserted into a column so that each individual table doesn't need to be parsed. New column IDs would be the unique primary key (SRA experiment, SRA project, SE, PE1, or PE2), QC program, QC metric, json data entry. In the end there will be 3 tables -- the metrics, the sample metadata, and a third table indicating which programs are supported by the DB and generally the types of inputs and outputs of each QC metric and other specific vocabulary (like, is it a variant calling experiment or RNAseq experiment, etc.).