NoSQL No More
technosophos.com
NoSQL No More
1–10 of 62 posts
Re: NoSQL No More
#2>Many people seem surprised that we, a tech-savvy startup, would be moving to an "old" technology.
Who is this "many?"
Re: NoSQL No More
#3This is why PostgreSQL is awesome. You can freely mix relational with non-relational (object) storage depending on your needs.
Re: NoSQL No More
#4>Many people seem surprised that we, a tech-savvy startup, would be moving to an "old" technology. Who is this "many?"
When I read stuff like this I try reeeeal hard to not immediately dismiss it as @hipsterhacker stereotypes, but weird groupthink like this shocks me.
Keeping data that is by it's nature relational in a relational database is, to my mind, obvious. That it isn't for startups that are building their entire business on data foundations (because it's OLD!) is genuinely mind-boggling to me. I guess I'm the one that's old now.
Re: NoSQL No More
#5>Many people seem surprised that we, a tech-savvy startup, would be moving to an "old" technology. Who is this "many?"
There's a sizable contingent (but still a tiny minority) of developers who will outright dismiss anything SQL and typically view databases as these things you kinda pick on a whim based on whatever is easiest to shoehorn your MVP into. Fancy things like a powerful query language, robust data types, transactions, ACID-compliance etc? YAGNI.
Although I don't share this view, I cant say its always wrong. If you're building simple MVPs to find product-market fit for ideas why bother? If there's a 90% chance what you're building will never evolve to need those features, why invest in them?
But if your "product" ends up being a 10% survivor you better have a plan to move to something more powerful before you compound too much technical debt from your NoSQL database. Once you start scaling your business and have to face competition, NoSQL becomes productivity tarpit. Queries that take 20 minutes to write and optimize in the SQL realm can turn into day-long exercises in NoSQL.
The reality is most developers aren't cranking out disposable software used to test the market for new ideas. We're working on things that already have a place, we just need to make them better. For us, the best option right now is SQL + maybe some specialized databases for certain purposes (Columnar for analytics, graph for relationship analysis, full-text for text, etc)
Re: NoSQL No More
#6The NoSQL data model - please read as document oriented - is fundamentally flawed because it forces you into denormalization without good reasons like performance optimization but with all the disadvantages.
The only good reason not to use a relational database is that they suck at modeling complex entities and their relationships. Shattering nice entities into small relations to get them normalized, adding join tables to model many to many relationships and all that fun. Everything that is not roughly tree-like is just painful.
More than once I finally decided to just stuff the really complex pieces into a blob - XML or what ever worked best - and just deal with it at the application layer. Not pretty, not fun, but still less painful than modeling and dealing with it in the relational model.
Re: NoSQL No More
#7The NoSQL data model - please read as document oriented - is fundamentally flawed because it forces you into denormalization without good reasons like performance optimization but with all the disadvantages. The only good reason not to use a relational database is that they suck at modeling complex entities and their relationships. Shattering nice entities into small relations to get them normalized, adding join tabl…
I'm with you here. I've found that even phones have enough juice to handle most manipulation, and the website appears more responsive because the server isn't bogged down.
Haven't scaled it yet, though...
Re: NoSQL No More
#8I'm sorry but all I need can be handled by simple key/value stores, and I prefer the simplicity of JSON data structures, without predefined fields.
Re: NoSQL No More
#9Hear hear!
Now can somebody convince the W3 and Mozilla that there's nothing wrong with implementing SQLite next to IndexedDB so that I can move forward without having to write an IndexedDB adapter for my clearly relational TV Show -> Season -> Episode data please?
https://github.com/SchizoDuckie/DuckieTV/blob/angular/js/CRU...
Foreign Relationships on foreign keys are not difficult
Many to many Relationships are not difficult
SQL is not difficult
Joining is not difficult
Grouping is not difficult
Now try to do that in IndexedDB / NoSQL, and suddenly you're in a world of hurt. It can work, but can it perform? Maybe. With time and patches. So wham, let's throw the option of implementing the probably most well tested piece of software (in the universe probably, see http://sqlite.org/testing.html ) out of the window.
Re: NoSQL No More
#10Typically, the best you can hope for out of your data is that it is a directed graph. Relational databases exist in a sweet spot of efficiency, widespread availability, and fairly decent ability to represent directed graphs.
But you need to know the shape of your graph first. The document-store model tends towards giving up the graph entirely and just going with a tree. Us programmers love tree structures. They make things nice and tidy and can be traversed in finite time.
But I've never worked on a project that could easily be modeled as a tree. Unfortunately, this was often realized after I had been working on the project for a year. You know how phenomenally fucked you are having a tree-like data structure when what you really need is a directed graph? You're basically all the fuckeds.
Directed graphs generalize trees, so trying to shoehorn a tree where a directed graph is needed is basically bringing a Fischer Price tool set with you to Habitat for Humanity.
Thus, from experience, I never start with a tree now. I always start with a directed graph. If I learn that the data is a tree after a year and not actually a directed graph, oh well, look at all this flexibility we didn't need.