5 ms·
I disagree -- an RDBMS is pretty much safe/sane for any design, though it may not be the fastest. NoSQL databases (specifically, eventually consistent DBs) are
by setr 6y ago
I disagree -- an RDBMS is pretty much safe/sane for any design, though it may not be the fastest. NoSQL databases (specifically, eventually consistent DBs) are only safe/sane in specific scenarios.
If you don't know what your needs are, you should always start with an RDBMS -- it's not that difficult to go "up" to a NoSQL db from there (you're only losing information, and if you can't safely move because of loss of ACID... you'd probably have been really fucked if you started off without it), but you can't easily migrate back "down" to the RDBMS -- a NoSQL database stores almost no information about your data or its constraints.
And your application will almost always want transactional guarantees and to model relationships properly -- generally only small chunks of the design (design-wise; data-wise it might be 90% of the app) can be treated with eventual consistency and have real scaling needs, which you can shift over to your nosql system.
Apps are generally just metadata tracking with a dash of real work.
- yawnxyz 6y agoas a UX designer / product engineer, it's easier for me to jump into a nosql than to wire up a postgres instance for a small proof of concept project that I know won't really go anywhere
- nucleardog 6y agosqlite? All my proof of concept (and some production) stuff just uses that until I need features or concurrency that it can’t provide.
- ndiscussion 6y agoSorry, this might come off as obtuse, I don't mean it that way. Perhaps I'm misreading your title, but I find it odd that a UX designer or product person would be the one writing proofs of concept that require a database. Unless you mean for solo projects? In that case, it may work for you, but if you're not a database expert, it makes sense you would work around your limitations. That doesn't necessarily mean it's a best practice.