Hi HN,<p>I work as full stack developer, but never really spent time on Database designs. I had written code to retrieve data out of DB, but never ever created a schema from scratch. So, I thought of doing some side project to understand how database design involves.<p>I had decided to create a Resume Builder Application. Here are some of the features that I had thought about:<p>* User can sign up to create his/her own resumes.<p>* User can have multiple resumes. (only applicable for paid users, for free users only one resume)<p>* Resume can be built from the UI (from available components) and user can save it as draft.<p>* Resume can be published via url.<p>* Published resumes stats like visitors count needs to be calculated.<p>* User can delete the resume.<p>* User can upload his/her pic.<p>* User can add description about themselves.<p>Given all these, I have come up with this schema:<p>https://ibin.co/3CoJEfeQTuAp.png<p>Here are the questions I have:<p>1. I have a general knowledge on RDBMS, so my schema targets databases like Oracle, MySql etc. But can we choose NoSql for this problem? If so why?<p>2. Is my schema correct? Does it work on large data with ease?<p>3. I thought of saving the resume layouts (layouts for each resume is decided by the user via say UI) in JSON format. Is it a good practice to use JSON datatypes?<p>4. ResumeData table serves to store the user data for each resume. Is it a good to have a separate table for the same?<p>5. If the answer for the first question is RDBMS, which database you will prefer? I had decided to use PostgreSql.<p>Thanks a lot for spending time on answering these questions.
It is probably easier to design a schema from a data-centric viewpoint rather than a user centric viewpoint. Schema are ontologies and ontologies answer the question, what the hell is it?<p>For example, a resume contains photo*. CRUD by the user is no different that CRUD by the site owner and no different from CRUD by a recruiter. Differences don't happen at the schema level they happen at the application level: recruiters and users and administrators might all stored in the people table and the application grants them different CRUD privileges and generates different views.<p>Ontology is largely orthogonal to whether the persistence is in a relational, key-value, or graph backing store.<p>Good luck.
You might want to look into versioning your resumes. A 'version' column in your ResumeData could be sufficient. And I wouldn't store images as blobs.<p>If resume components are highly volatile and mostly text, I'd probably go for a simple KV table, instead of adding new columns to ResumeData. Then you could also put versioning there. Alternatives would be a JSON column or a proper table-per-component schema.<p>I wouldn't worry about "large data" if you're going with Postgres. You'll mostly enter that territory by storing lots of changes and updates, which just doesn't happen that much with a traditional