alanyuchenhou / athanasea

Advanced virtual animal rescue web app (CAUTION: site under construction)
https://athanasea.herokuapp.com
MIT License
3 stars 3 forks source link

database design and layout #28

Closed lordofire closed 8 years ago

lordofire commented 8 years ago

As per information from road map in wiki section, we need to come up with first round prototype of database design and layout for both client/server sides.

lordofire commented 8 years ago

From my current understanding, I think we could use the following scheme to maintain the data for this app.

  1. Administrative accessible model database: define all the common detailed resources for different aquatic species. This is pure information reference database and should only be modified if we want to add more information to each species or add a new species. For example, in this database we will maintain information for animals like dolphin, sea lion, and so forth, and keep information like name, stage, photo, preferred habitat, preferred food, threat, etc for each species.
  2. Administrative rescuing animal pool database: list all the animals that is current available to be adopted and collected. Will refer to model database for detailed animal info, with additional entries like valid adoption period and so forth. This database will be updated more frequently than model database and is managed by us. This table could be set per client or globally. Globally one is easy to maintain, but hard to scale, and per client one is on the contrary. I would prefer global one for now, because it is simpler to implement and maintain.
  3. Client's own database: list all the animals client has adopted through game and the detailed status of each one, like their health, mood, hungry status, etc. User has exclusive control on this database, and should be updated subject to users's usage.
alanyuchenhou commented 8 years ago

Mongodb is suitable to handle complex data with nested schema, but not operations combining data such as join. And I think that's why normally people use as less collections as possible when using mongo. For now, our 2 collections - animals and spp(species) should be enough. The most important enhancement we need now is to add more fields into the Subsp(subspecies, its a subschema within in SpSchema). Specifically, it needs a list of stages. The stage(a new subschema within Subsp) needs to contain fields: age(when the subspecies reach this stage), image(how the subspecies look in this stage). There will be more work on the client side to correctly display them for a specific animal.