Evaluation of the Contig-alias's data model

[waterflow80]

@tcezard
I've been trying to define best data model that suits our needs in the implementation of the sequence-collection API.

I've concluded that using the contig-alias's already existing data-model can be beneficial, but still have some weaknesses.

These are some of the pros and cons of using the contig-alias data model that I've come up with:

• Pros:
  1. Using an existing data model that can store all the attributes of the sequence collection that we need.
  2. Using an existing data model which already has all (or most of) its CRUD implemented and tested.
  3. Having a centralized data that can be used for multiple uses and needs.
  4. Not having the same data saved in different tables; the contig-alias 's and the sequence-collection ones.
• Cons:
  1. Being dependent to the contig-alias's database and API. So the change of the data through the contig-alias' API will have a direct effect on the sequence-collection's API and on the type of response it will return.
  2. Being limited to the already existing naming conventions that exist in the Contig-alias's database. No elasticity..

I think that the most determinant issue that allows us to make an evaluation of whether we should use the existing data-model or make a new one, is the no-elasticity issue related to naming conventions. If we can tolerate that, I think it will be more useful to use the existing data-model.

Another thing is the need for an independent sequence-collection API. If this feature is required in our API, so we should use an independent data model. But still use some of the contig-alias's functionalities.

I would love to have your feedback on this.