6

I'm designing a very simple application to send positive text messages to subscribers at a certain frequency.

These are just famous, motivational, encouraging and positive quotes.

When I first thought of the idea I thought, oh we can just store these quotes as one Collection in MongoDB. And the phone #s in a separate Collection

If the app remains as simple as this...then is a NoSQL approach ideal and better than a RDBS? I feel like it'd lead to faster dev time to get something up and running (Node Stack)

However, I think making the little initial extra effort and using MySQL could make this more expendable, future-proof, and prevent technical debt. Say...I want to track what Quotes were sent out to specific users, etc..

What are some insights?

This question isn't even about the app itself, but rather to get a better idea of when to use NoSQL vs a traditional RDBMS.

Update When I say NoSQL..I pretty much mean MongoDB or any other similar JSON document store

Thanks!

9
  • 3
    If I were you and you're considering an RDBMS, I'd give serious consideration to PostgreSQL - a vastly superior system to MySQL in most ways! Jun 15 at 11:07
  • Still never used PostgreSQL! Just MySQL and MariaDB fork. I keep hearing its better. Why so exactly? You could even link a blog. Jun 15 at 13:21
  • 1
    Consider sqlite Jun 15 at 17:31
  • 1
    @user2402616 - see my comment above. Also, you can search for "PostgreSQL vs. MySQL". There are many who swear by MySQL (I used to) until I discovered (in fairness, mostly, but not all, documented) niggle after niggle after...! You can look here & here (PostgreSQL vs. MongoDB for documents - you can pick and mix your models). Having said that, PostgreSQL is not a panacea and in the interests of honesty, you could look at why Uber moved to MySQL. Jun 16 at 5:28
  • 1
    Here, but for an analysis see here - also, check out PostgreSQL's feature matrix - how many of these are available in MySQL? Jun 16 at 5:28

1 Answer 1

13

If the app remains as simple as this...then is a NoSQL approach

If the app is truly as simple as this and will remain so, and dev time is the key factor, then a pair of files and a bash script (or a few lines in any language) would do. On day 216 (assuming daily frequency) send the quote from line 216 of the quotes file to all the contacts currently in the address-book file. Even NoSQL (assuming you mean a “relatively schema-less document store”) would be overkill in terms of storage design. This would leave you more time for putting together the content (the quotes and the contacts list) and sorting out procedures for things like if a user wants to unsubscribe.

However, I think making the little initial extra effort and using MySQL could make this more expendable, future-proof, and prevent technical debt.

I would suggest that is time well spent, as long as you don't go too far away from a minimal viable proof-of-concept as your first version. But be aware that you can over-engineer or under-engineer in NoSQL systems just as much as you can in SQL based ones.

to get a better idea of when to use NoSQL vs a traditional RDBMS

The general answer is to use another solution when you don't need the benefits of a traditional RDBMS or the ones that you need can be achieved/emulated by something else with less dev time. You can't make this decision well without deciding what your minimal feature set will be, and what you are likely to want to add later.

“NoSQL” covers a number of different ideas, some of it useful abstractions and some of it marketing fluff, so to get a more specific answer to that you need to say what you mean by NoSQL. Do you have some no-sql options in mind?


Not an awfully helpful answer, I'm sure, but without a more specific question we can't give a more specific answer (except perhaps by copy-pasting some marketing material for “nosql” solutions, but that information you can find easily anyway.

2
  • 2
    No this is very helpful. I like the rudimentary design of a couple files and a bash script. I also like how you mention the marketing fluff of nosql haha. Marketing fluff is an underrated topic in tech I feel. Leads to a lot of overengineering and wasted time Jun 15 at 0:28
  • But will it really stay that "simple"?
    – Rick James
    Jun 21 at 5:06

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.