As it stands now, I am looking at the following setup:
MySQL DB in the backend to hold all information about awards and tie them to movies with specific TheMovieDatabase IDs
The app will hold a snapshot of all data on an SQLite DB (for speed and offline access), which should be updated whenever new data is added/modified in the server end (this should not happen frequently (only about once or twice a month)
Firebase to handle user authentication, user management, Watchlists and Watched lists
Some conclusions I reached by reading around:
PostgreSQL seems overkill for such a simple application
I do not need the scalability or speed NoSQL seems to offer as the database is simple and only occasionally updated
I might eventually add text search (ElasticSearch seems super interesting), but for now, I will only work with filtering based on switching things on and off ("show only OSCARS", or show only the "awards for best movie"). In the future I'll probably add movie search....
Does any of the above sounds wrong/bad/weird to you, fellow experience devs?? :)
It's pronounced Diane. I do data architecture, operations, and backend development. In my spare time I maintain Massive.js, a data mapper for Node.js and PostgreSQL.
Why are you considering using three databases for a simple application? Start with one, and break specific domains out if and when you need to.
Scalability and speed are not inherent attributes of NoSQL databases. Many of them are designed with an eye to both, but it's not to be taken for granted. Something like Cassandra, for example, would be very bad for your application because it's optimized for high write volume and you're mostly reading. HBase would be bad because you can't do ad-hoc queries easily. Meanwhile, relational databases can scale well enough until you're Amazon or Google tier (even Instagram runs on Postgres), and designed correctly they're plenty fast.
Last, if you're considering MySQL you should think about Postgres; they're in the same weight class, and I would use Postgres over MySQL in a heartbeat. Overkill only matters when you add unnecessary complexity, such as for example splitting your data layer across three independent DBMSs before you've even gotten anything off the ground.
Sounds like a cool project. I made a really simple app with the movieDB api when I was first learning iOS. I've been meaning to do an app with this API again. Where you can tweet a movie review from the movie app along with the movie poster.
You might be able to get away with just CoreData and a MovieDB client without using PostgreSQL (assuming you're building a native app). But that's just my two cents. I'm still learning!
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Alright, thanks for all the replies! :)
As it stands now, I am looking at the following setup:
Some conclusions I reached by reading around:
Does any of the above sounds wrong/bad/weird to you, fellow experience devs?? :)
Thanks!
Best,
Daniel
Why are you considering using three databases for a simple application? Start with one, and break specific domains out if and when you need to.
Scalability and speed are not inherent attributes of NoSQL databases. Many of them are designed with an eye to both, but it's not to be taken for granted. Something like Cassandra, for example, would be very bad for your application because it's optimized for high write volume and you're mostly reading. HBase would be bad because you can't do ad-hoc queries easily. Meanwhile, relational databases can scale well enough until you're Amazon or Google tier (even Instagram runs on Postgres), and designed correctly they're plenty fast.
Last, if you're considering MySQL you should think about Postgres; they're in the same weight class, and I would use Postgres over MySQL in a heartbeat. Overkill only matters when you add unnecessary complexity, such as for example splitting your data layer across three independent DBMSs before you've even gotten anything off the ground.
Sounds like a cool project. I made a really simple app with the movieDB api when I was first learning iOS. I've been meaning to do an app with this API again. Where you can tweet a movie review from the movie app along with the movie poster.
You might be able to get away with just CoreData and a MovieDB client without using PostgreSQL (assuming you're building a native app). But that's just my two cents. I'm still learning!