3 ms·

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. If resume

by mhd 10y ago

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. 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. 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

antoaravinth 10y ago
Thanks for your answer. I have few questions: >> You might want to look into versioning your resumes. A 'version' column in your ResumeData could be sufficient. I didn't quite get this. Why do we need to add 'version' column to ResumeData? Lets say when user updates the resume, my intention was to just replace the data accordingly (as now you have told, I might use JSON column and just replace it with the value). In this case why 'version' is required? And why not storing images as blobs? Any drawbacks? But thanks for your insights, it really helped me.
- mhd 10y ago
  Even if you don't want to let (paid?) users access their previous revisions, it's an easy way to have basic undo functionality. You'll get "Help, I deleted my whole work history and don't want to enter it again!" support requests or disappointed users ("I can just hit Ctrl-Z in Word, why do I bother with this?"). Take care of stuff like this in the beginning and it will save you some headache later. Images as blobs for webapps are generally a bad idea. You can't do a lot with them in databases (browse, analyse, join etc.). There's some overhead if you fetch them from the DB for each request, so they'll end up in some file-based cache anyway. Save that step and just put the path or filename in the DB. Or if you've got one image anyway, just ditch the column and have /img/users/<db_pk>.png.
  - antoaravinth 10y ago
    Thanks a lot! It really helps!

by mhd 10y ago

antoaravinth 10y ago

Thanks for your answer. I have few questions: >> You might want to look into versioning your resumes. A 'version' column in your ResumeData could be sufficient. I didn't quite get this. Why do we need to add 'version' column to ResumeData? Lets say when user updates the resume, my intention was to just replace the data accordingly (as now you have told, I might use JSON column and just replace it with the value). In this case why 'version' is required? And why not storing images as blobs? Any drawbacks? But thanks for your insights, it really helped me.

mhd 10y ago
Even if you don't want to let (paid?) users access their previous revisions, it's an easy way to have basic undo functionality. You'll get "Help, I deleted my whole work history and don't want to enter it again!" support requests or disappointed users ("I can just hit Ctrl-Z in Word, why do I bother with this?"). Take care of stuff like this in the beginning and it will save you some headache later. Images as blobs for webapps are generally a bad idea. You can't do a lot with them in databases (browse, analyse, join etc.). There's some overhead if you fetch them from the DB for each request, so they'll end up in some file-based cache anyway. Save that step and just put the path or filename in the DB. Or if you've got one image anyway, just ditch the column and have /img/users/<db_pk>.png.
- antoaravinth 10y ago
  Thanks a lot! It really helps!